Sinnvolle Benennung / Struktur

[Johannes]

Hallo

Ich habe zwei Tabellen die heissen

tbl_products
------------
pro_id
pro_name

und

tbl_options
-----------
opt_id
opt_name

...und nun gibt es eine Beziehung zwischen den beiden Tabellen die in einer dritten Tabelle abgebildet werden. (Optionen werden bestimmten Produkten zugewiesen) Wie benenn ich die am besten?

tbl_products_options?

und die Felder?

proOpt_id?
proOpt_pro_id?
proOpt_opt_id?

Wird irgendwie umständlich, trotzdem möchte ich eine sinnvolle Benennung. Hat jemand eine Idee?

Johannes

[Magic Mike]

Moin

ich gehe mal davon aus, das diese dritte Tabelle eine Referenz Tabelle ist. Zum Auflösen halt.

Es ist sinnvoll Namen bei zu behalten. Also wenn in Tabelle
A Produkt = prod benamst ist, dann sollte in Tabelle B
Produkt auch "prod" heissen.

regds
Mike

[Götz]

Hallo Johannes!

tbl_products_options?

Warum nicht?

und die Felder?

Ich würde sie id, pro_id und opt_id nennen.

Wird irgendwie umständlich, trotzdem möchte ich eine sinnvolle Benennung. Hat jemand eine Idee?

Benenne sie einfach so, wie Du es "sinnvoll" findest.

Kannst ja in einer kleinen Tetdatei mal noch aufschreiben, wofür welche Tabelle da ist usw., daß jemand anders außer dir etwas mit den Namen anfangen kann, aber solange nur Du mit der Datenbank arbeitest kannst du alles so nennen, wie es Dir paßt.

MfG
Götz

[Tom]

Hello,

tbl_products

id_products

name

und

tbl_options

id_options
name

...und nun gibt es eine Beziehung zwischen den beiden Tabellen die in einer dritten Tabelle abgebildet werden. (Optionen werden bestimmten Produkten zugewiesen) Wie benenn ich die am besten?

tbl_products_options?

und die Felder?

id_products_options
id_products
id_options?

1. ID_ ist Präfix. Das lässt sich auch mit SQL später leichter finden
   als ein Postfix
2. Primärschlüssel heißen so, wie ihre Tabellen, nur mit anderem Präfix
   Die Präfixe bei den Tabellen kann man bei MySQL getrost weglassen,
   da es auch in der nächsten Version noch keinen Views oder Stored
   Queries geben wird.
3. Die Sekundärsschlüssel heißen ganz genauso, wie die Primärschlüsel in
   den relateten Tabellen, da man sonst "using" nicht einsetzen kann.
   Ob es sich beim Schlüssel um einen Fremdschlüssel handelt, kann man
   erstens am Tabellennamen und zweitens am PRI oder KEY in "show columns
   from $table" ablesen. Ich hatte dazu mal eine Funktion
   $_info = get_info($con, $table)  veröffentlicht.

Polymorphie endet spätestens an der Gleichartigkeit der Namen...

Wird irgendwie umständlich, trotzdem möchte ich eine sinnvolle Benennung. Hat jemand eine Idee?

Johannes

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

Tom

[Tom]

Hello,

Sorry, die verschiedenen Schlüsselarten bei MySQl sind

PRI
MUL
UNI
...

<img src="http://bitworks.de/~selfHTML/mysql_keys.jpg" border="0" alt="">

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

Tom

[Johannes]

1. ID_ ist Präfix. Das lässt sich auch mit SQL später leichter finden
      als ein Postfix

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

2. Primärschlüssel heißen so, wie ihre Tabellen, nur mit anderem Präfix
      Die Präfixe bei den Tabellen kann man bei MySQL getrost weglassen,
      da es auch in der nächsten Version noch keinen Views oder Stored
      Queries geben wird.

Es geht um MSSQL, nicht um MySQL

[Tom]

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

[Johannes]

Hello,

tbl_products

id_products

name

und

tbl_options

id_options
name

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

[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

[Lude]

Hi,

Ich habe zwei Tabellen die heissen

tbl_products

pro_id
pro_name

und

tbl_options

opt_id
opt_name

...und nun gibt es eine Beziehung zwischen den beiden Tabellen die in einer dritten Tabelle abgebildet werden.

welche Beziehung, eine "1:n", "1:1" oder "n:m"(mein Tipp, dieses Mal ;-)? Davon solltest  Du Deine Benennung ableiten.

Gruss,
Lude

"Wer nicht fragt, bleibt doof."

[Johannes]

welche Beziehung, eine "1:n", "1:1" oder "n:m"(mein Tipp, dieses Mal ;-)? Davon solltest  Du Deine Benennung ableiten.

n:m Beziehung...es geht darum, den verschieden Produkten Optionen zuzuweisen. Dabei kann ein Produkt mehrere Optionen und eine Option zu mehreren Produkten gehören...

[Christian Seiler]

Hallo Johannes,

tbl_products_options?

IMHO ja.

und die Felder?

proOpt_id?

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.

proOpt_pro_id?
proOpt_opt_id?

Eventuell auch nur pro_id und opt_id? Oder po_pro_id und po_opt_id?

Viele Grüße,
Christian

[Johannes]

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.

So kann einem Product(z.B. Notebook) eine Option (z.B. Akku) zugewiesen werden. Erscheint ein Nachfolgemodell des Akkus, muss die alte Beziehung bestehen bleiben und eine neue wird hinzugefügt...

[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

[Johannes]

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.

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

[Christian Seiler]

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

[Johannes]

Hallo

Vorerst einmal Danke für eure Hilfe. Ich werde das ganze nocheinmal überarbeiten. Wenn ich fertig bin, werde ich mein Resultat nochmals zur Bewertung in einem neuen Thread aufzeigen.

Gruss Johannes