Wie geht man mit zusammengesetzten Primärschlüsseln um?

[Der schöne Günther]

Nehmen wir (vereinfacht) an, es gäbe diese zwei Tabellen:

Code:

Artikel
---------
artikel_id1: Int
artikel_id2: Int
artikelName: Str
[PKEY: artikel_id1, artikel_id2]

Beschreibung
------------
artikel_id1: Int
artikel_id2: Int
sprache: Str
beschreibungstext: Str
[PKEY: artikel_id1, artikel_id2, sprache]
[FKEY: artikel_id1, artikel_id1 -> Tabelle Artikel]

Ja, das ist beim besten Willen keine professionelle E/R-Notation.

Ich möchte nun in einer TDBLookupComboBox die für einen Artikel zur Verfügung stehenden Beschreibungs-Sprachen anzeigen. Ich kann der Box bei KeyField aber natürlich nur ein einziges Feld mitgeben.

Meine Idee wäre, dass man sicher aus den beiden PKEY-Feldern zusätzliches, einzelnes Pseudo-Feld erstellen könnte und darauf verweisen. Ich wüsste aber nicht, wie. Müsste man da an der entsprechenden Tabellen-Komponente ansetzen und dort manuell ein Feld hinzufügen?

Oder gibt es eine ganz andere Möglichkeit?

[Neutral General]

Hallo,

Was wäre mit einem künstlichen Primärschlüssel?
Damit umgeht man so einen Ärger.

[himitsu]

Entweder du baust deine Tabelle so um, daß es nur noch einenen Primärschlüssel gibt.

Oder du nimmst in das Select, oder die Tabelle (könnte man via Trigger füllen und synchron halten), oder als CalcField, ein Neues Feld auf, welches eine zusammengesetzte ID enthält.



Müsste der Foreign-Key nicht eigentlich auch aus den beiden Feldern bestehen?

[Der schöne Günther]

Ja, der Fremdschlüssel soll auch aus beiden Feldern bestehen. Wird aus der unbeholfenen Textdarstellung wohl nicht wirklich deutlich.

Ich habe beiden Tabellen mal ein künstliches Feld (Typ: String) hinzugefügt. Ist
artikel_id1 = 5
artikel_id2 = 536
dann ist
Artikel_idCOMBINED = 5.536

Das war einfacher als gedacht und klappt auch. Nur leider kommt die Lookup-Combobox, oder eher: Das DataSource damit nicht zurecht. Bei Anwendungsstart fliege ich mit einer Exception, dass er ein Feld mit diesem Namen nicht finden kann, raus.

Wen es interessiert, hier der Callstack:

Code:

:7672c41f KERNELBASE.RaiseException + 0x58
FireDAC.Stan.Error.FDException(???,???,???)
FireDAC.Stan.Error.FDException($2F5C180,???,2,???)
FireDAC.DatS.TFDDatSNamedList.ErrorNameNotFound('meineTabelle_idCOMBINED')
FireDAC.DatS.TFDDatSNamedList.ItemByName('meineTabelle_idCOMBINED')
FireDAC.DatS.TFDDatSBindedList.ItemByName('meineTabelle_idCOMBINED')
FireDAC.DatS.TFDDatSColumnList.ColumnByName('meineTabelle_idCOMBINED')
FireDAC.DatS.TFDDatSColumnSublist.Fill(???,'meineTabelle_idCOMBINED',nil,nil)
FireDAC.Comp.DataSet.TFDDataSet.InitLocateRow('meineTabelle_idCOMBINED','1.43')
FireDAC.Comp.DataSet.TFDDataSet.LocateRecord('meineTabelle_idCOMBINED','1.43',[],-1)
FireDAC.Comp.Client.TFDTable.InternalLocateEx('meineTabelle_idCOMBINED','1.43','',[],nil)
FireDAC.Comp.Client.TFDTable.LocateEx(???,'1.43',???,nil)
FireDAC.Comp.DataSet.TFDDataSet.Locate('meineTabelle_idCOMBINED','1.43',???)
Vcl.DBCtrls.TDBLookupControl.LocateKey
Vcl.DBCtrls.TCustomDBLookupComboBox.KeyValueChanged
Vcl.DBCtrls.TCustomDBLookupComboBox.UpdateListFields
Vcl.DBCtrls.TListSourceLink.ActiveChanged
Data.DB.TDataLink.SetActive(???)
Data.DB.TDataLink.UpdateState
Data.DB.TDataLink.DataEvent(???,0)
Data.DB.TDataSource.NotifyLinkTypes(deUpdateState,0,True)
Data.DB.TDataSource.NotifyDataLinks(deUpdateState,0)
Data.DB.TDataSource.SetState(???)
Data.DB.TDataSource.UpdateState
Data.DB.TDataSet.AddDataSource($2FC89B0)
Data.DB.TDataSource.SetDataSet($2F87910)
System.TypInfo.SetOrdProp(???,???,???)
System.Classes.TPropFixup.ResolveReference(???)
System.Classes.GlobalFixupReferences
System.Classes.TReader.ReadRootComponent($2F222C0)
System.Classes.TStream.ReadComponent($2F222C0)
System.Classes.InternalReadComponentRes(???,???,$2F222C0)
System.Classes.InitComponent(TMainForm)
System.Classes.InitInheritedComponent($2F222C0,TForm)
Vcl.Forms.TCustomForm.Create(???)

Ich glaube, ich bin alle hieraus resultierenden Übel selbst schuld. Einfach einen künstlichen Primärschüssel nehmen und das ganze Artikelnummer-Geraffel in eine neue Tabelle auslagern. Das wäre wohl in jeder Hinsicht besser.

[DeddyH]

Du musst ja nicht unbedingt auslagern, sofern Deine DB ansonsten normalisiert ist. Füge doch einfach den künstlichen PK hinzu und definiere die Kombination des jetzigen zusammengesetzten PK als UNIQUE, das sollte schon helfen. Den FK setzt Du dann auf den neuen PK.

[Der schöne Günther]

Das Problem war aber ein ganz anderes: Ich hatte das neue Feld in meiner Tabellen-Komponente eingefügt. Ein Feld mit FieldKind = fkCalculated . Ein DBGrid browst auch ganz lässig dadurch. Aber die Lookup-Combobox scheint damit nicht zurechtzukommen.

Zumindest würde ich das jetzt so interpretieren.

Oder ist ein "calculated Field" sowieso der falsche Ansatz und ich muss irgendwas mit den "Lookup-"-Eigenschaften drehen?

[Sir Rufo]

Wenn du bei den kombinierten PKs bleiben willst, dann musst du dir entweder Views basteln, die diesen virtuellen PK erstellen oder du musst dich von den DataAware-Controls verabschieden.

[sx2008]

Zitat von Der schöne Günther:

Ich kann der Box bei KeyField aber natürlich nur ein einziges Feld mitgeben

Beide PK-Felder getrennt durch einen Strichpunkt - schon getestet?

[p80286]

Warum machst Du solche Klimmzüge?

Code:

Artikel:
Artikel_ID [PK]
Artikel

Beschreibung:
Beschreibung_ID [PK]
Artikel_ID  [FK]
Sprache

sollte voll und ganz ausreichen.
(daß die PKs aus dem Generator kommen setz ich mal als selbstverständlich voraus)

Code:

select sprache from Beschreibung where Artikel_ID=:Artikel_id;

Gruß
K-H

[Hansa]

Zitat von p80286:

..daß die PKs aus dem Generator kommen setz ich mal als selbstverständlich voraus..

Au mann. Ich setze jedenfalls mal voraus, dass die Generatoren dazu benutzt werden, wozu sie gedacht sind : als transaktions-unabhängige also quasi auch Datenbank-unabhängige Zähler. Am Besten interpretiert man da nicht noch eine Pseudo-Logik hinein.

Zusammengesetzte Primary Keys sind wohl auch nicht besinderss gute Idee. Wozu gibts denn Unique Keys ?