INSERT in zwei Tabellen und UNIQUE-Index???

[romber]

Es gibt als Beispiel zwei Tabellen: "Artikel" und "Anbieter". Tabelle "Artikel" ist mit der Tabelle "Anbieter" durch einen Foreign Key verknüpft. Mehrere Felder in der Tabelle "Anbieter" sind mit einem UNIQUE-Index verbunden, um doppelte einträge zu verhindern.

Wie ist jetzt der richtige Weg, den Tabellen einen neuen Datensatz hinzu zu fügen?

[Union]

Na zuerst die Anbietertabelle mit allen benötigten Constraints und dann den Artikel mit Referenz auf den Anbieter.

[romber]

Vielen Dank für die schnelle Reaktion!

Zitat von Union:

Na zuerst die Anbietertabelle mit allen benötigten Constraints und dann den Artikel mit Referenz auf den Anbieter.

Das ist soweit klar. Das Problem ist, dass es beim UNIQUE-Konflikt keine Referenz auf den bereits vorhandene Anbieter zurückkommt, sondern nur die Meldung, dass es halt den Konflikt gibt. Muss ich vorher jedesmal prüfen, ob der Anbieter bereits existiert oder gibt es eine elegantere und schnellere Methode?

[Union]

Das ist ja eben elegant. Ein Post ist nicht möglich wenn etwas nicht stimmt, und es ist zentral in der Datenbank zentral hinterlegt. Du musst nur die Exception ggf. abfangen und dem User vermitteln.

[romber]

Zitat von Union:

Du musst nur die Exception ggf. abfangen und dem User vermitteln.

Stimmt, wenn es um einen einzelnen Datensatz geht und der User die Exception haben möchte. Was aber, wenn es um bis zu 120 Datensätze pro Sekunde geht, die man über eine Datenschnittstelle übermittelt bekommt und "unbeaufsichtigt" in einer Schleife mittels Prepared Statements so schnell wie möglich der Datenbank hinzufügen soll? Dann ist die o.g. SELECT-Abfrage über die Anbieter-Tabelle ein gnadenloser Performance-Killer. Deswegen war ich gespannt, ob es noch eine schönere Methode gibt...

Edit: Natürlich muss man nicht zwingend vor jedem INSERT diese SELECT-Abfrage ausführen. Es würde reichen, wenn man die Exception abfängt und erst dann die Referenz auf den Anbieter holt. Aber im meinem bekomme ich die Daten immer von denselber Anbietern, so dass es nach gewisser Zeit praktisch jeder INSERT ein UNIQUE-Konflikt auslösen würde.

[Union]

Ja wie sieht denn das CONSTRAINT Konstrukt aus - ist das wirklich so fies? Was sind die Feldtypen die geprüft werden? Und wie immer bei MSSQL kann man durch Schrauben mit Statistiken und Indexen sicher was erreichen. Übrigens hängt es auch davon ab bei welchem Feld es fehlschlägt, denn es kann ja ggf. mehrere Duplikate diesbezüglich geben.

Ansonsten steht der Key in der Exception:

CREATE UNIQUE INDEX terminated because a duplicate key was found. Most significant primary key is '%S_KEY'.
oder
Cannot insert duplicate key row in object '%.*ls' with unique index '%.*ls'.

[romber]

Die Feldtypen sind fast alle vom Typ NVARCHAR. Ich musste dieses Typ nehmen, weil es sich bei vielen Anbieter um ausländische, meistens osteuropäische, Firmen handelt und die viele Firmennamen und personenbezogene Daten ganz oder Teilweise in Unicode bedürfen.

[romber]

Zitat von Union:

Ansonsten steht der Key in der Exception:

CREATE UNIQUE INDEX terminated because a duplicate key was found. Most significant primary key is '%S_KEY'.
oder
Cannot insert duplicate key row in object '%.*ls' with unique index '%.*ls'.

Ich glaube, ich krieg jetzt die Kriese! Genau so einen Exception-Text möchte ich gerne haben, aber bei UniDAC habe ich das eben nicht! Ich habe nur die Meldung, dass ein Fehler aufgetretten ist. War das ADO? Ich dachte mir, die DB-Komponenten geben bei den Exception die genauen DB-Engine-Meldungen wieder, deswegen habe ich ADO nicht mal ausprobiert.

[Union]

Nein, das sind die Meldungen vom SQL-Server. Die müssen ja irgendwie ankommen. Aber irgendwie scheint mir das Konstrukt der Plausibilisierung nicht überzeugend zu sein. Kannst Du nicht mit Anbieter-IDs arbeiten von vornherein? Und dann nur bei Neuanlage, Änderung die kompletten Daten in einer separaten EDI?

[romber]

Zitat von Union:

Kannst Du nicht mit Anbieter-IDs arbeiten von vornherein? Und dann nur bei Neuanlage, Änderung die kompletten Daten in einer separaten EDI?

Das ist das Problem. Es gibt keine AnbieterID.