SQL sowas wie exists für viele rows

SQL sowas wie exists für viele rows (13 Beiträge, 314 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi,

ich hab 2 tabellen (bzw. eins davon ein view um andre sachen auszuschliessen)

tabelle 1:
ID        name          seriennr
1         productx      1
1         productx      2
1         productx      3
1         productx      4
1         producty      1
1         producty      2
1         producty      3

view 2:
name     seriennr
productx      1
productx      2
productx      3
productx      4
producty      1
producty      2
producty      3

was ich möchte:
Die ID wird von mir generiert. also ich schau immer in den view 2, generiere eine ID, speichers in tabelle 1 und entfern das zeug aus dem view. Soweit kein problem.

Nun möchte ich prüfen ob es schon eine ID gibt die die zumindest einige einträge aus view 2 beinhaltet (aber KEINE zusätzlichen), und die ID zurückliefern. Es darf aber kein Eintrag mit der ID in Tabelle 1 existieren dens nicht in der View gibt. In dem Fall muss ich eine neue ID generieren.

wie mach ich das am blödsten?

mit cursor wär unpraktisch da es irgendwann mal SEHR viele IDs und Produkte geben wird

bildlich vorgestellt:
sagen wir ich packe sachen in kisten, und verteile nummern. die nummern und den inhalt speichere ich ab. nun nimmt wer eine kiste und packt was rein, der zettel mit der nummer der auf die kiste getackert war ist aber weg. er möchte nun wissen, ob es eine nummer gibt, bei der er sein neu reingepacktes zeug dazuschreiben kann, und wenn ja, welche das ist, oder ob er eine neue nummer vergeben muss.

13.02.2014, 13:53 Uhr - Editiert von zeddicus, alte Version: hier

Der würde dann ja wenns blöd läuft mehrere Nummern zurückbekommen oder? Weil productx kann ja in Nummer 1, 2 oder sonstwo sein..

Was willst du in diesem Fall tun?
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Nein, sollte eigentlich nicht sein vorkommen. Das ist durch den produktionsprozess ausgeschlossen

Dann ist ein Produkteintrag IMMER eine Nummer oder??

Ansonsten verstehe ich deine Beschreibung irgendwie nicht ganz oder deine Datendarstellung, da diese im Widerspruch sind.. :/
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Ansonsten verstehe ich deine Beschreibung irgendwie nicht ganz oder deine
Datendarstellung, da diese im Widerspruch sind

weder, noch.

Ich verstehe dein Problem nicht ...

Richtig wäre es, wenn du mit select einfach eine Überprüfung machst ...
Oder du lässt den view gruppieren damit es keine doppelten Einträge gibt ...
Oder du definierst einen eindeutigen Schlüssel und verlässt dich darauf das die Datenbank schreit wenn du einen Wert doppelt anlegen willst ...

1.) Wie stellst du das "entfernen" aus einer View an?
2.) Die Beschreibung ist äußerst wirr.

Wozu überhaupt die View? Mir scheint als wäre die nur unnötiger Ballast. Bei deiner Beschreibung kannst dir das komplett sparen und solltest auch. Schließlich ists ja nur eine Teilmenge deiner Tabelle.

pong

"Ein Gewitter reinigt die Luft", sagte ein Mann, nachdem ein Blitz seine Frau erschlug

Wozu überhaupt die View? Mir scheint als wäre die nur unnötiger Ballast. Bei
deiner Beschreibung kannst dir das komplett sparen und solltest auch

nein ist sie nicht, da ich das ganze an sehr vielen stellen verwende und der view somit schneller (und angenehmer) ist als den subquery jedesmal compilen zu müssen.

1.) Wie stellst du das "entfernen" aus einer View an?

Na wie wohl? Indem ich die Datensätze in der dahinter liegenden Tabelle so modifiziere, daß sie in dem View nicht mehr aufscheinen.

Die Beschreibung ist äußerst wirr.

Das ist möglich, der Produktionsprozess ist halt mal so

Kann auch sein daß ich in meiner Erklärung einen Knoten drinhatte.

Aber versuchen wir es nochmal:

Ich habe eine Tabelle T1 mit:

ID, ChargenNummer, Seriennummer

und eine View mit
ChargenNummer, Seriennummer

Auf einen gewissen Trigger muss ich die Produkte die gerade in der View sind nehmen, die nächste freie ID in T1 suchen, und alle Records aus der View mit der neuen ID in T1 schreiben.

Nun kann es uU. passieren, daß alle diese Records + zusätzliche nochmal in der View auftauchen, und ich möchte dann die selbe ID wie letztes mal hergeben.

Im Prinzip müsste ich mir in diesem Fall wohl alle IDs aus T1 raussuchen bei denen die Chargennummern aus der View vorkommen, und dann schauen, ob für eine dieser IDs der intersect von T1.ID, T1.ChargenNummer, T1.Laufnummer und T1.ID, View.ChargenNummer, View.Laufnummer wiederum T1.ID, T1.ChargenNummer, T1.Laufnummer bei dieser ID entspricht. Wenn ja, kann ich die ID wieder vergeben, wenn nein muss ich eine neue vergeben.

Ok, als Text klingt es wieder wirr. Ich probiers mal mit einem Excel Beispiel:

In diesem Fall dürft ich die ID 3 nicht zuteilen, da diese andere zusätzliche Einträge enthält.
ID 4 dürfte ich zuteilen, da sie genau diese Einträge enthält. ID 6 ist nur ein weiteres Beispiel, die dürfte ich auch zuteilen, da sie nur Einträge aus der View enthält, aber nix zusätzliches. Eigentlich kann die ID 6 aber nie zustande kommen, da in diesem Fall ja auch wieder die ID 4 zugeteilt werden hätte sollen, und zusätzliche Records für die ID4 eingetragen worden wären.

Ev. ists jetzt verständlicher. Wenn nicht, auch nicht tragisch, dann bastel ich was.

Am Datenmodell gibts nichts zu ändern, da kann jammern wer will, das ist vom Kunden so vorgegeben.

17.02.2014, 04:57 Uhr - Editiert von zeddicus, alte Version: hier

als den subquery jedesmal compilen zu müssen.

"compilen" ... ich ahne böses. Welches DBMS haben wir im Einsatz und um welches Datenvolumen dreht es sich denn?

Die Problemstellung ist heute wenigstens klar.

pong

"Ein Gewitter reinigt die Luft", sagte ein Mann, nachdem ein Blitz seine Frau erschlug

Ich rufe von C# aus auf einem MSSQL Server SPs auf. Das Datenvolumen für Tabelle 1 wird nach einem Jahr ca. bei 320k records liegen. Zugriffe auf den View erfolgen von verschiedenen Seiten

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung