Insert - PRIMARY KEY automatisch anlegen

[user0815]

Hi,

angenommen ich habe 2 Tabellen mit jeweils folgenden Feldern:

T_DATA: DATA_ID, USER_NO, USW_FELD, ...
T_USER: USER_NO, USERNAME, STREET, ...

Jetzt ist T_DATA.USER_NO der FOREIGN KEY auf T_USER.USER_NO.

Importiere ich jetzt Daten für die Tabelle T_DATA so muss die USER_NO in der Tabelle T_USER ja schon vorhanden sein, ansonsten knallt es.
Wie kann ich bei einem Import automatisch eine neue entsprechende USER_NO anlegen ?
Oder muss ich per SQL zuerst eine Abfrage auf vorhanden sein der USER_NO ausführen, wenn nein einfügen & dann erst den Datensatz in T_DATA schreiben...

Danke für die Hilfe...

[mkinzler]

Am Besten die Benutzertabelle zuerst anlegen. Oder den Index/Schlüssel temporär deaktivieren

[Blup]

Für den Import besten eine "Stored Procedure" anlegen, der die Daten übergeben werden, die alle Bedingungen prüft und je nach Fall reagiert.
Ändert sich später etwas an der Tabellenstruktur muss nur diese angepasst werden und der Import funktioniert weiterhin.

[Perlsau]

Zitat von user0815:

Hi,

angenommen ich habe 2 Tabellen mit jeweils folgenden Feldern:

T_DATA: DATA_ID, USER_NO, USW_FELD, ...
T_USER: USER_NO, USERNAME, STREET, ...

Jetzt ist T_DATA.USER_NO der FOREIGN KEY auf T_USER.USER_NO.

Importiere ich jetzt Daten für die Tabelle T_DATA so muss die USER_NO in der Tabelle T_USER ja schon vorhanden sein, ansonsten knallt es.
Wie kann ich bei einem Import automatisch eine neue entsprechende USER_NO anlegen ?
Oder muss ich per SQL zuerst eine Abfrage auf vorhanden sein der USER_NO ausführen, wenn nein einfügen & dann erst den Datensatz in T_DATA schreiben...

Danke für die Hilfe...

Natürlich mußt du zuerst abfragen, ob es deinen Benutzer schon gibt: IF Dataset_T_User.Locate('USERNAME',BenutzerName,[]) THEN ... . Gibt es den schon, dann übernimmst du die durch Locate ermittelte USER_NO. Wenn nicht, legst du den neuen User an und übernimmst danach die neu angelegte USER_NO. Bestimmt hast du USER_NO als Primary-Key eingestellt und dieser Spalte Auto-Inc-Trigger und -Generator verpaßt ...

[user0815]

USER_NO ist Primary-Key, stimmt, aber kein Auto-Inc. Die Nummer müssen nicht zwingend fortlaufen sein (obiges ist auch nur ein verkürztes Bsp).
Hatte evtl. gedacht das man es über einen Trigger lösen kann, also Daten einfügen & die evtl. Exception abfangen & hier dann die USER_NO anlegen...

Werde es aufgrund der referentiellen Integrität also richtig machen (müssen): Abfragen ob USER_NO bereits vorhanden, wenn nein erst anlegen & dann erst den T_DATA DS einfügen...

@Blup
Mit "Stored Procedure" kenne ich mich noch nicht aus, evtl. später mal einlesen...

@mkinzler
Benutzertabelle erst anlegen. Daran habe ich auch gedacht, können allerdings bis zu 3k DS werden von denen 'wahrscheinlich' die meisten nicht genutzt werden. Habe das verworfen.

[Perlsau]

Zitat von user0815:

USER_NO ist Primary-Key, stimmt, aber kein Auto-Inc. Die Nummer müssen nicht zwingend fortlaufen sein (obiges ist auch nur ein verkürztes Bsp). Hatte evtl. gedacht das man es über einen Trigger lösen kann, also Daten einfügen & die evtl. Exception abfangen & hier dann die USER_NO anlegen...

Beim Verwenden von Autoinc-Feldern geht es nicht in erster Linie darum, eine fortlaufende Nummerierung zu erzeugen, sondern sicherzustellen, daß ein derart erzeugter Index eindeutig ist, indem er nur einmal vergeben wird. Die fortlaufende Numerierung ist dabei sozusagen ein Nebeneffekt, der nur in sehr seltenen Fällen wirklich benötigt wird (ich hatte erst einen solchen Fall, da war die fortlaufende Numerierung gesetzlich vorgeschrieben).

Da du sicher keine Redundanz in deiner DB wünschst und aus diesem Grund User und Data in zwei Tabellen unterbringst, kommst du um die Prüfung, ob ein User bereits eingetragen ist bzw. das Neuanlegen eines Users nicht herum. Und 3000 Datensätze sind ein Klacks und sogar via Delphi-Code schnell erledigt.