Primär - Schlüssel ???

[Holger Teetz]

Hallo zusammen !

Ich versuche gerade in die Datenbankprogrammierung mit Delpih einzusteigen. Eine vermutlich dämliche Frage stellt sich mir jedoch.

Ich habe eine Tabelle mit einer Spalte Nummer als Primärkey. Wenn ich nun ein TTable.Insert ausführe, muß ich dieser Spalte einen wert zuweisen und dieser darf ja nur einmal vorkommen. Die Frage ist wo bekomme ich einen freien Wert für dewn Primärschlüssel her ? Gibt es da eine funktion im TTbale ? Muß ich mir die separat irgendwo speichern ?

Für euere hilfe bedanke ich mich schon mal.

Gruß,

Holger Teetz

[Andreas Kosch]

Hallo,

die meisten Datenbanken stellen intern eine Funktion bereit, die einen INTEGER-Primärschlüssel automatisch hochzählt. Ja nach Datenbank hat dieser Mechanismus eine andere Bezeichnung: <br>
a) Paradox: Kennzeichner <i>Zähler</i> für die Spalte<br>
b) ACCESS: Kennzeichner <i>AutoWert</i> für die Spalte<br>
c) MS SQL/MSDE: Kennzeichner <i>IDENTITY</i> für die Spalte<br>
d) InterBase: Wert des <i>GENERATOR</i> vorher abfrage

[Jürgen Thomas]

Hallo,

der Vorschlag von Andreas Kosch ist natürlich die erste Wahl. Dazu und ergänzend möchte ich auf Folgendes hinweisen.

* Bei einem ftAutoInc-Feld braucht kein Wert vorgegeben zu werden:<BR>
Table1.Append => Felder eingeben, Zähler 'übergehen', Table1.Post bzw.<BR>
Table1.AppendRecord( [nil, andere Felder] )<BR>
Bei dem letzten Befehl muss bekanntlich die Reihenfolge der Felder im Formular bzw. Datenmodul eingehalten werden (in der Regel die persistenten Felder); das ftAutoInc-Feld wird der Datenbank überlassen.

* Grundsätzlich wird empfohlen, dass ein Primärindex nicht aus mehreren Feldern besteht (ich glaube, das habe ich schon vor Jahren bei Andreas Kosch gelesen), weil dann die Wartung der Tabelle und referenzielle Integrität erschwert werden. Statt dessen sollte in einer solchen Situation der Primärindex ein ftAutoInc-Feld sein, und der 'inhaltliche' Hauptindex wird durch einen (gewarteten) Sekundärindex ersetzt.

* Dennoch gibt es Situationen, in denen ein einzelner numerischer Wert als Primärindex festgelegt wird, aber kein ftAutoInc-Feld sein darf (z.B. eine Adressendatei, in der die Adressennummern nicht fortlaufend, sondern gezielt vergeben werden). In einem solchen Fall verfahre ich ungefähr wie folgt:

(1) Im Formular setze ich ein numerisches Feld 'NumEdit1: TNumEdit' nächste freie Nummer suchen ab... (für TNumEdit gibt es viele freie Komponenten, z.B. TCustomNumEdit der RX-Tools)

(2) Beim Befehl Table1.Insert/Append sucht das Programm selbständig die nächste freie Nummer iNextNumber:<BR>
Table1.DisableControls<BR>
iNextNumber := NumEdit1.Value;<BR>
if Table1.FindKey( [iNextNumber] )<BR>
then begin<BR>
repeat<BR>
Inc(iNextNumber);<BR>
until not Table1.FindKey( [iNextNumber] );<BR>
end;

(3) Mit diesem Wert wird der neue Datensatz angelegt:
NumEdit1.Value := iNextNumber + 1;<BR>
Table1.Append;<BR>
Table1Feld1.AsInteger := iNextNumber;<BR>
Table1.EnableControls;<BR>
usw.

Ich hoffe, diese Tipps bringen weiter.

Jürge

[Andreas Kosch]

Hallo,

&gt;..in der die Adressennummern nicht fortlaufend, sondern gezielt vergeben werden..

nach der "strengen Lehre" darf in einem Primärschlüssel keine fachliche Information gespeichert werden, weil es ansonsten gleich 2 Problem gibt: <br>
1. Das Programm muss den Primärschlüsselwert selbst bestimmen.<br>
2. Die Datenbank kommt immer dann in Schwierigkeiten, wenn sich die Geschäftsregeln so ändern, dass davon auch der Primärschlüssel betroffen ist.

Um das 2. Problem zu vermeiden, sollte die im Beispiel genannten Adressnummer als zusätzliche Spalte angelegt werden (der SQL-Standard spricht in diesem Fall von einem <i>Candidate Key</i>, da diese zusätzliche Spalte ebenfalls die Aufgabe des Primärschlüssels übernehmen könnte, es aber wegen der striktuen Trennung von den Geschäftsregeln nicht "darf").

Je nach den Anforderungen an die Anwendung muss man aber nicht immer die "strenge Lehre" befolgen, so dass pragmatische Kompromisse durchaus üblich sind :-