Hello,

Das ist mir neu, warum? Hatte ID immer als Postfix verwendet

Es ist leichter mit einer Abfrage herauszufinden, wo sich Felder mit Substr($feld, 1,3) = "ID_" befinden, als Felder mit dem Inhalt "...-id...", bei dem id dann aber am Ende stehen muss. Die "Rightstring"-Funktionen fehlen meistens oder sind langsam.

Jede berechtigte Datenbank wird eines Tages beim "Digger" zum "Datamining" landen *ggg* (unberechtigte braucht man gar nicht erst anzulegen)

Es geht um MSSQL, nicht um MySQL

Dann mag ein Präfix sinnvoll sein. MSSQL kennt Views? Und die können dann auch gespeichert werden und werden behandelt wie eine Tabelle? Habe leider im Moment keine Litaratur dafür zur Hand.

Liebe Grüße aus http://www.braunschweig.de

Tom

Hello,

und die andern Felder erhalten keinen Präfix? (z.B. prod_name, prod_description...)?

Wozu? Damit man dann später in der Abfrage anfamgen muss zu stottern?

select products.prod_name, options.opt_name from tbl_products, tbl_options using ID_products

select procucts.name, options.name from products, options using id_products

(ich habe jetzt mal n:m weggelassen)
Ich bin der Meinung, dass das vollkommen gut so ist. Da muss man nichts mehr verschlüssel, was sowieso schon klar ist. Bei der id_ handelt es sich um ein vertikales Präfix, nicht um ein horizontales. Bei prod_ und opt_ würde es sich aber um horizontale Präfixe handeln, die ohnehin schon durch die Punktschreibweise  table.field  abgedeckt sind.

Also bitte nix doppelt einbauen.

Liebe Grüße aus http://www.braunschweig.de

Tom

Hello,

Wozu brauchst Du das Feld? In einer Verknüpfungstabelle für eine n:m-Relation (also eine solche Tabelle, wie sie bei der Normalisierung 2. Grades entsteht) brauchst Du keine eigene ID; es reicht, wenn der Primärschlüssel der Verknüpfungstabelle ein zusammengesetzter Schlüssel aus den beiden IDs, die verknüpft werden sollen, ist.

Eigentlich hast du schon Recht. Da ich aber später möglichst einfach Beziehungen zwischen diesen Tabellen löschen und erstellen möchte, kann mir eine zusätzliche ID für die Beziehung nützlich sein.

Und uneingentlich hat sich in der Praxis gezeigt, dass an dieser Stelle meistens noch eine Historie-Funktion hinzukommt und dann ist der Kombinationsschlüssel plötzlich nicht mehr primär. Nun wäre natürlich der der neue Schlüssel über id_products-id_options-timerange der primäre. Aber dann müsste man alle alten Relationen zu dieser Tabelle auch überarbeiten. Es wäre ja denkbar, dass hier noch eine Tabelle mit Service-Notes andockt, die zu jeder Paarung noch 0-n Servicenotizen enthält.

Also eigenen Schlüssel drinlassen.

Das vereinfacht die Weiterentwicklung des Systems.

Liebe Grüße aus http://www.braunschweig.de

Tom

Hallo Johannes,

Was versteht man unter einem zusammengesetzten Schlüssel? Dann hätte ich einfach nur die beiden Felder options_id und products_id?

Ein zusammengesetzter Schlüssel ist ein Schlüssel, der sich über mehrere Felder erstreckt. In Deinem Fall würde dann also praktisch die options_id und die products_id _gemeinsam_ den primären Schlüssel abgeben.

Primärschlüssel heißt ja nichts anderes als ein Kriterium, das dazu dient, Zeilen in einer Relation eindeutig zu identifizieren - und das wäre mit beiden IDs ja gegeben.

Viele Grüße,
Christian