zusammengesetzter Primary Key

[daniel71]

Hallo

Nach längerem suchen und lesen bin ich eher verwirrt...

Delphi-Quellcode:

   with ADOQuery4 do Begin  
    Close;
    SQL.Text:= 'CREATE TABLE BenutzteNSs_Text (' +
                'PBX_Num_Am INT NOT NULL,'+
                'Board INT NOT NULL,'+
                'Port INT NOT NULL,'+
                'NText nvarchar(50),'+
                ')';
    ExecSQL;
   end;

ich möchte die spalte PBX_Num_Am, Board und Port als zusammengesetzter primary key definieren, aber wie mache ich das?

In der MSDN habe ich nur gefunden dass es geht, aber wie es geht nicht
PRIMARY KEY-Einschränkungen
Ich habe da was von UNIQUE INDEX gelesen, aber nirgens ein code-beispiel wie und wo ich das einsetzte.
Kann mir jemand bitte bitte den obigen code abändern, dammit ich ein beispiel habe?

Gruss Daniel

[grenzgaenger]

Zitat von daniel71:

Hallo

Nach längerem suchen und lesen bin ich eher verwirrt...

Delphi-Quellcode:

   with ADOQuery4 do Begin  
    Close;
    SQL.Text:= 'CREATE TABLE BenutzteNSs_Text (' +
                'PBX_Num_Am INT NOT NULL,'+
                'Board INT NOT NULL,'+
                'Port INT NOT NULL,'+
                'NText nvarchar(50),'+
                ')';
    ExecSQL;
   end;

musste nciht. probiers mal so:

Delphi-Quellcode:

   with ADOQuery4 do Begin  
    Close;
    SQL.Text:= 'CREATE TABLE BenutzteNSs_Text (' +
                'feld1 integer, '+
                'feld2 integer, '+
                'feld3 varchar(10), '+
                'und_noch_feld varchar(80), '+
                'primary key (feld1, feld2, feld3)' + 
                ')';
    ExecSQL;
   end;

[hoika]

Hallo,

oder jetzt nachträglich

SQL-Code:

alter table tab1 add constraint idx_tab1_prim 
primary key(feld1,feld2)

Ich rate aber davon ab.
Nimm lieber eine künstliches Feld (id integer)

Der prim key wird bei mssql gern als clustered index
benutzt, d.h. der Record wird so wie der prim key schon sortiert abgelegt,
geht schneller. Und mit Id ist das sehr einfach zu machen.


Heiko

[norwegen60]

Hallo zusammen,

mein Problem geht in eine ähnliche Richtung. Ich habe Daten an mehreren Standorten. Nun sollen am Zentralstandort alle Daten auf dem MsSQL-Server liegen. Z.B. durch abendlichen Abgleich. Die Tabellen sind jetzt schon mit einem ID = Integer-Feld ausgestattet und zusätzlich mit der Standortkennung ServORT = char(1). Nun sehe ich zwei Möglichkeiten:
die ID-Felder durch den Typ uniqueidentifier belegen
einen zusammengesetzten Primary-Key verwenden
Bei dem Typ uniqueidentifier fehlt mir, dass Übersichtlichkeit verloren geht, wenn man mal schnell mit den Rohdaten arbeitet. Eine 3-, 4- oder auch 5-stellige Zahl kann man sich ja noch merken, aber bei einem Uniqueidentifier-Feld (z.B. {5B95B455-C0EE-4109-A7C1-3A02D7015D92}) ist das unmöglich. Und manchmal, bei der Fehlersuche, ist es eben doch hilfreich, wenn man die Daten noch lesen kann.

Welche Probleme sind aber bei vielen Master-Detailverbindungen zu erwarten?
Spielt es für die Verarbeitungszeit eine Rolle, in welcher Folge ich den Primary-Key bilde (also primary key(ServOrt, ID) oder besser primary key(ID, ServOrt)?
Gibt es u.U. Probleme mit anderen Datenbanken als MsSQL, z.B. mit FireBird oder MySQL?

Welche Empfehlungen gebt ihr für sowas, wenn man die Tabellen neu aufbauen würde?

[noidic]

Ich habe in solchen Fällen bisher immer einen zusammengesetzten Schlüssel verwendet, dabei muss man dann halt drauf achten, bei joins und Filtern die Felder in der richtigen Reihenfolge (also in der, in welcher sie im PK angegeben sind) verwendet werden.
Ich bin bisher immer damit gut gefahren, gerade weil die Herkunft des Datensatzes sofort ersichtlich ist.

[hoika]

Hallo,

unter FB benutze ich Nummernkreise und einzelne Ids (Integer.
Die neue Nummer wird vor dem Insert per SP aus der DB unter
Berücksichtigung der Nummernkreise ermittelt.

Das ganze wird intern als Sequenz (Generator) geführt.


Heiko

[norwegen60]

Hallo Heiko,
ich denke du verstehst unter Nummernkreise Bereiche, z.B. für Standort1 0..19999, Standort2 20000..39999 usw. Das Habe ich unter Paradox auch schon mal gemacht. Blöd nur, wenn plötzlich eine Tabelle doch größer wird als mal angenommen. Und wirklich elegant ist es nicht, oder?

Hallo noidic,
handelte es sich um eine größere Anwendung? Wenn ja, wie war dann die Performance? Bei mir sind es ca. 160 Tabellen von 20 bis mehrere 10.000 Datensätze. Zur Zeit ca. 1.4GB ohne dass Bilder oder Dokumente darin abgespeichert sind. Die sind noch immer als eigene Dateien auf dem Server.
Nachteil: Sie sind leichter manipulierbar und man kann nicht in den Dateien suchen
Vorteil: Sie sind auch da, wenn die Datenbank mal nicht läuft.

[daniel71]

Hallo

@ grenzgaenger

funktioniert ja tip top

@ hoika zur Antwort #2

in meinem fall ist es nicht nötig dies nachträglich zu machen, ist aber immer gut zu wissen wie dies geht.
Zu deinem vorschlag den primary key mit einem künstlichen feld zu machen: Die kombination dieser drei felder muss einmalig sein, und ich dachte mir dass ich genau durch die verknüpfung dieser drei felder das auch zwingend erreiche.

Die überprüfung dafür überlasse ich dem SQL-server und fange dann eine allfälige excepion ab.

Habe zwar kaum erfahrung, aber ich glaube auf die perormance muss ich kaum achten da die ganze DB ziemlich klein ist. Etwa 8 Tabellen mit max 300 datensätzen.

vielen dank für eure hilfe!