(STRUKTUR)
0 0 
dedlfix
(STRUKTUR)
Hallo
Vorweg: Bin müde.
Nun:
Ich speichere Infos (Augenfarbe, Haarfabe etc.) von Personen in meiner Datenbank ab. Folgende Tabellen habe ich: Augenfarben, Haarfarben, Personen.
Verlinkt sind die Tabellen je über ihre Id, also Personen.AugenfarbeId linkt zu Augenfarben.Id. Dasselbe gilt für die Haarfarbe.
Nun möchte ich noch eine weitere Eigenschaft für jede Person speichern, und zwar die Sprache(n), welche diese Person beherrscht. Wie dem "(n)" entnommen werden kann, kann eine Person durchaus mehrere Sprachen sprechen. Meine Frage zielt nun darauf ab, wie ich diese zusätzliche Info am Besten in meiner Datenbank unterbringe. Benötige ich dafür eine weitere Tabelle? Muss ich die SprachenId komma-getrennt speichern?
Also: Gute Nacht.
Tschüss
Capior
-
Hi,
Nun möchte ich noch eine weitere Eigenschaft für jede Person speichern, und zwar die Sprache(n), welche diese Person beherrscht. Wie dem "(n)" entnommen werden kann, kann eine Person durchaus mehrere Sprachen sprechen. Meine Frage zielt nun darauf ab, wie ich diese zusätzliche Info am Besten in meiner Datenbank unterbringe. Benötige ich dafür eine weitere Tabelle? Muss ich die SprachenId komma-getrennt speichern?
Stichwort "n:m"-Beziehung, d.h. Du benötigst eine zusätzliche Tabelle für die Sprachen.
Harry B
-
yo,
Stichwort "n:m"-Beziehung, d.h. Du benötigst eine zusätzliche Tabelle für die Sprachen.
wohl eher zwei zusätzliche tabellen, eine für die etntiät sprachen und eine beziehungstabelle.
Ilja
-
yo,
hallo
wohl eher zwei zusätzliche tabellen, eine für die etntiät sprachen und eine beziehungstabelle.
Danke dir für die Antwort. Ich habe folglich mal folgendes konstruiert (Access 2003):
Lässt sich was einsparen? Sieht das ganze einigermassen iO aus?
Danke!
Ilja
Ciao
Capior-
Hi Capior !
modelId-------------------->Model_to_Lang--------->ID_to_Lang
modelID number; LangID number;
LangID number; Language varchar;1-------------------------->1,17------------------>17,"Deutsch"
1,18------------------>18,"Englisch"
1,19------------------>19,"Französisch"17 = "Deutsch"
18 = "Englisch"
19 = "Französisch"Select Languages from ID_to_Lang a, Model_to_Lang b, where a.LangID=b.LangID and a.modelID=1 order by 1 asc;
Ergibt:
"Deutsch"
"Englisch"
"Französisch"In der Model_to_Lang-Tabelle stehen nicht die Sprachen, sondern nur die ID's drin, da ein number kleiner ist als ein String und somit weniger Platz braucht. In er ID_to_Lang-Spalte stehen dann die Sprachen und die entsprechenden ID's. Somit bleibt letztere relativ konstant wohingegen die Model_to_Lang-Tabelle je nach Bildungsgrad der Personen relativ schnell wachsen kann (spätestens dann, wenn der Papst Mitglied wird ;-))
Gruß
Hans
-
yo,
In der Model_to_Lang-Tabelle stehen nicht die Sprachen, sondern nur die ID's drin, da ein number kleiner ist als ein String und somit weniger Platz braucht.
wie kommst du den bitte auf diese aussage ?
Ilja
-
Hi
wie kommst du den bitte auf diese aussage ?
Tja, also, man kann doch einem number sicherlich sagen: Sei nicht 28 Byte groß sondern nur 10 Byte oder 3 Byte oder wie auch immer. Richtig?
Gruß
Hans
-
yo,
Tja, also, man kann doch einem number sicherlich sagen: Sei nicht 28 Byte groß sondern nur 10 Byte oder 3 Byte oder wie auch immer. Richtig?
das hat aber nichts damit zu tun, dass in der beziehungstabelle nur die fremdschlüssel stehen, sondern basiert vielmehr darauf, die integrität der daten zu gewähren.
Ilja
-
-
-
-
yo,
Lässt sich was einsparen? Sieht das ganze einigermassen iO aus?
sieht schon sehr gut aus. man könnte überlegen, ob man nicht die beiden entitäten male und female nicht zusammenlegt und dann eben ein paar attribute hat, die nicht alle geschlechter besitzen.
auch die beziehungen zu den augenfarbenund haarfarben könnte man sich sparen und eventuell diese beiden direkt in die entität tabellen nehmen. das spart wie dedlfix schon gesagt hat joins, welche bei grossen datenmengen eine nicht unerhebliche rolle spielen. um dennoch die farben als vorlagen benutzen zu können, mann man entweder einen set spaltentyp definieren oder aber eine tabelle als vorlage benutzen, aus der man dann die entsprechenden werte für haarfarbe und augenfarbe ausließt.
Ilja
-
Hi,
meinst du, dass es bei Frauen eine endlich lange Liste von möglichen
Haarfarben gibt, bzw. dass sie sich auf eine ungefähre Farbangabe
reduzieren lassen würden? Und für jede neue Nuance immer wieder die
Enumwerte zu ändern, ist auch nicht das Gelbe vom Ei.Ciao, Frank
-
yo,
meinst du, dass es bei Frauen eine endlich lange Liste von möglichen
Haarfarben gibt, bzw. dass sie sich auf eine ungefähre Farbangabe
reduzieren lassen würden?mir persönlich ist es egal, wieviele farben nun ausgewählt werden können. aber bei dem datenmodell, das ich meine, spielt es keine rolle, ob da nun 5 farben vorgegeben sind oder 100.
Ilja
-
Bei der verwendung eines "set" spaltentyps müsste er aber für jede
neue Farbe, die zur Auswahl stehen soll, die Definition, also die
Inhalte der Enumeration anpassen.Finde ich nicht gerade gelungen.
Ciao, Frank
-
yo,
Bei der verwendung eines "set" spaltentyps müsste er aber für jede
neue Farbe, die zur Auswahl stehen soll, die Definition, also die
Inhalte der Enumeration anpassen.Finde ich nicht gerade gelungen.
Set war ja auch nur einer der vorschläge. wenn sich die daten des öfteren ändern, kannst du alle haarfarben in eine extra tabelle schreiben, die als vorlage für die programme dient. insofern muss man für jede zusätzliche farbe, nur einen datensatz in der vorlagentabelle einfügen und viola passen sich alle programe automatisch an. ich finde das sehr gelungen und man spart sich die zusätzlichen JOINS.
Ilja
-
-
-
-
yo,
hallo
sieht schon sehr gut aus. man könnte überlegen, ob man nicht die beiden entitäten male und female nicht zusammenlegt und dann eben ein paar attribute hat, die nicht alle geschlechter besitzen.
Sprich: eine Tabelle, wobei dann bei den Männern einige Zellen leer bleibne und dies dann auto. auf einen Mann schliesst. Oder: ncoh eine boolean isMale (o. ä.) einfügen?
auch die beziehungen zu den augenfarbenund haarfarben könnte man sich sparen und eventuell diese beiden direkt in die entität tabellen nehmen. das spart wie dedlfix schon gesagt hat joins, welche bei grossen datenmengen eine nicht unerhebliche rolle spielen. um dennoch die farben als vorlagen benutzen zu können, mann man entweder einen set spaltentyp definieren oder aber eine tabelle als vorlage benutzen, aus der man dann die entsprechenden werte für haarfarbe und augenfarbe ausließt.
Jup, die Daten werden nicht allzugross werden, sodass ein weiterer Join kein Problem darstellen wird/sollte.
Ilja
Danke dir
Capior
-
-
Hi,
Grundsätzlich: Es ist okay, es scheint deine Anforderungen
ausreichend abzudecken. Aber es beinhaltet unnötige Elemente.Was unterscheidet ein "Male Model" von einem "Female Model"?
Haben diese beiden Entitäten eine grosse Überlappung ihrer
Attributsarten? Bei Männern würde mir jetzt quasi schon ein
"unique" Attribut ad-hoc einfallen.Was unterscheidet eine Haar _Farbe_ von einer anderen Farbe
in ihrem Informationsgehalt?Zudem könntest du die Attribute selbst als Entitäten behandeln
und die Eigenschaftswerte der Personen in vertikaler Ausrichtung
speichern.Also insgesamt 1 Tabelle "Person / Model" mit allen direkten
statischen Attributen wie "Name", "Geschlecht", "Geburtstag".
Eine Tabelle für variable "Attribute" wie eben Haarfarbe, usw.
Eine Tabelle, die dann die Entität "Attribut" mit der Entität
"Person" und einem spezifischen Wert verlinkt. Zu den einzelnen
möglichen Attributen wie Kleidergrössen, Farben, Sprachen
könntest du dann immer noch eine "Auswahlliste" mit den jeweilig
möglichen Werten zuordnen.Diese Variante hat auch den Vorteil, dass du im Nachhinein durch
einfaches Hinzufügen neuer Datensätze zur Tabelle "Attribute"
neue Eigenschaften zur "Person" speichern kannst, ohne das
Tabellenschema von "Person" ändern zu müssen.So long,
Frank
-
-
-
-
echo $begrüßung;
Ich speichere Infos (Augenfarbe, Haarfabe etc.) von Personen in meiner Datenbank ab. Folgende Tabellen habe ich: Augenfarben, Haarfarben, Personen.
Verlinkt sind die Tabellen je über ihre Id, also Personen.AugenfarbeId linkt zu Augenfarben.Id. Dasselbe gilt für die Haarfarbe.Wenn es sich um eine überschaubare Menge an Werten für eine Eigenschaft handelt, und diese Menge sich quasi nicht ändert, könnte sich ein Set oder eine Enumeration als einfacher handzuhaben erweisen, spart man sich doch dadurch weitere Tabellen und beim Abfragen pro Eigenschaft mindestens einen Join.
MySQL beispielsweise bietet dafür die Feldtypen SET und ENUM an.
echo "$verabschiedung $name";