Datenbankstruktur für ein Umfragesystem

[gottlieb]

Nabend Forum,
ich möchte eine Umfrage in eine Community einbinden und wollte nachfragen, wie ihr die Datenbankstruktur in etwa findet.

Tabelle: Poll
Poll_ID, Umfragetext, Datum, Mitglied_ID, LastVoteDate

In diese Tabelle legt ein Mitglied eine Umfrage an. Die möglichen Antworten werden eine separate Tabelle geschrieben.

Tabelle: Pollanswers
Question_ID, Poll_ID, Answer

Tabelle: Poll_Log
In diese Tabelle kommen dann die Bewertungen von den einzelnen Mitgliedern. Hier werden dann auch die Hits (count) für jede mögliche Antwort berechnet. Jedes Mitglied darf pro Umfrage nur einmal Voten.
Question_ID, Mitglied_ID

Naher müsste ich mit 4 Tabellen Joinen, da ich noch Userdaten auch noch brauche vom Mitglied_ID. Ist die Struktur für eine Umfrage so in Ordnung oder ist das so bedenklich, wenn man irgendwelche Features in die Umfrage einbauen will. Wenn jemand Ideen und Tipps haben sollte, nur zu :-)

Grüße

[Cheatah]

Hi,

Tabelle: Poll
Poll_ID, Umfragetext, Datum, Mitglied_ID, LastVoteDate

LstVoteDate klingt nicht nach etwas, das Teil der Umfrage ist ...

Tabelle: Poll_Log
Question_ID, Mitglied_ID

... sondern sich hieraus ermitteln lässt, wenn das VoteDate gespeichert wird.

Naher müsste ich mit 4 Tabellen Joinen, da ich noch Userdaten auch noch brauche vom Mitglied_ID. Ist die Struktur für eine Umfrage so in Ordnung oder ist das so bedenklich, wenn man irgendwelche Features in die Umfrage einbauen will.

Abgesehen von obiger Kleinigkeit erscheint mir das Layout zielführend zu sein. Zumindest kannst Du es leicht erweitern, wenn Du z.B. merkst, dass Umfragen von und bis einem Datum laufen sollen (btw: nenne "Datum" am besten gleich in das um, was Du meinst).

Cheatah

[gottlieb]

Moin,

Tabelle: Poll
Poll_ID, Umfragetext, Datum, Mitglied_ID, LastVoteDate

LstVoteDate klingt nicht nach etwas, das Teil der Umfrage ist ...

Die Spalte sollte eigentlich die letzte Aktivität anzeigen. (Wann es das letzte Mal in dieser Umfrage teilgenommen wurde)

Tabelle: Poll_Log
Question_ID, Mitglied_ID

... sondern sich hieraus ermitteln lässt, wenn das VoteDate gespeichert wird.

Also dann hier eine neue Spalte anlegen, wann an der Umfrage teilgenommen wurde.

Abgesehen von obiger Kleinigkeit erscheint mir das Layout zielführend zu sein. Zumindest kannst Du es leicht erweitern, wenn Du z.B. merkst, dass Umfragen von und bis einem Datum laufen sollen (btw: nenne "Datum" am besten gleich in das um, was Du meinst).

Ah ja, genau das ist eine Idee. Evtl. bestimmte Umfragen zeitlich begrenzen und manche nicht. Da bräuchte ich dann evtl. ein INT-Feld noch in "t_Polls", ob die einzelne Umfrage zeitlich begrenzt ist oder nicht.

Gäbe es eventuell noch gute Funktionen für ein schönes Umfragescript?

Was haltet ihr eigentlich davon, wenn das Mitglied die Möglichkeit hat, sein abgegebenes Voting im Nachhinein zu ändern, wenn man sich doch anders entscheidet.

Grüße

[Frank (no reg)]

Servus,

Also dann hier eine neue Spalte anlegen, wann an der Umfrage teilgenommen wurde.

Also ganz sicher nicht das. Du möchtest lediglich das Feld (in einer von Anfang an angelegten Spalte vom Typ DATETIME) mit einem Wert belegen, wenn in die Tabelle ein neuer Datensatz eingetragen wird.

Die Spalte sollte eigentlich die letzte Aktivität anzeigen. (Wann es das letzte Mal in dieser Umfrage teilgenommen wurde)

Das musst du aber nicht explizit speichern!! Anders gefragt, wie willst du dafür sorgen, dass dort ein Wert dann drin steht?

Was willst du mit einem Integer Feld für eine zeitliche Begrenzung? Zwei Felder (Spalten)

• VonDatum (entweder NULL oder expliziter Datumswert)
• BisDatum (entweder NULL oder expliziter Datumswert)

Wenn NULL in BisDatum dann ist sie immer gültig. ... :)

Was haltet ihr eigentlich davon, wenn das Mitglied die Möglichkeit hat, sein abgegebenes Voting im Nachhinein zu ändern, wenn man sich doch anders entscheidet.

Was soll ich speziell davon halten? Ist das eine notwendige Anforderung deines Kunden (im Zweifel von dir selbst) oder nicht? Wenn ja, dann bau die Möglichkeit ein, wenn es dir nicht zu schwierig ist. Wenn nicht, dann lass es.

Ciao, Frank

[gottlieb]

Grüzzi,

Das musst du aber nicht explizit speichern!! Anders gefragt, wie willst du dafür sorgen, dass dort ein Wert dann drin steht?

Was willst du mit einem Integer Feld für eine zeitliche Begrenzung? Zwei Felder (Spalten)

• VonDatum (entweder NULL oder expliziter Datumswert)
• BisDatum (entweder NULL oder expliziter Datumswert)

Wenn NULL in BisDatum dann ist sie immer gültig. ... :)

Genau, das ist natürlich auch möglich, bzw. viel besser so. :-)

Was haltet ihr eigentlich davon, wenn das Mitglied die Möglichkeit hat, sein abgegebenes Voting im Nachhinein zu ändern, wenn man sich doch anders entscheidet.

Was soll ich speziell davon halten? Ist das eine notwendige Anforderung deines Kunden (im Zweifel von dir selbst) oder nicht? Wenn ja, dann bau die Möglichkeit ein, wenn es dir nicht zu schwierig ist. Wenn nicht, dann lass es.

Die Umfrage ist für mich selbst, also keine Anforderung von einem Kunden. War eh nur eine Überlegung, ob ich das einbinden soll.
Umfragebeispiel zeitlich nicht begrent: Welche Reiseziele bevorzugt ihr?

1. Italien
2. Kroation
3. Spanien
4. Türkei
5. Griechenland

Irgendwann gibt es dummerweise öfters terroristische Anschläge in einem Rieseland, weswegen man seine Meinung nach Monaten ändern kann. Vorausgesetzt, die Umfrage wird öfters aufgerufen. :-)

Grüße

[Frank (no reg)]

Grüzzi,

Dafür würden Schlumpf Reto und Hefti oben auf dem Rigi an der Zunge aufhängen. :)

Das war jetzt aber keine Anspielung auf Personen, die zufällig den Namen Reto Schlumpf tragen. Kenne selbst 3 persönlich.

Das mit dem Ändern einer Abstimmung, wie gesagt, wenn du magst, tu es. (Just do it.)

Wobei ich vielleicht kein UPDATE machen würde sondern ein INSERT ;)

Ciao, Frank

[gottlieb]

Hi,

Dafür würden Schlumpf Reto und Hefti oben auf dem Rigi an der Zunge aufhängen. :)

Das war jetzt aber keine Anspielung auf Personen, die zufällig den Namen Reto Schlumpf tragen. Kenne selbst 3 persönlich.

Das mit dem Ändern einer Abstimmung, wie gesagt, wenn du magst, tu es. (Just do it.)

Wobei ich vielleicht kein UPDATE machen würde sondern ein INSERT ;)

Warum ein Insert? Dann hätte ich ja zweimal gevotet?

Grüße

[Cheatah]

Hi,

LstVoteDate klingt nicht nach etwas, das Teil der Umfrage ist ...
Die Spalte sollte eigentlich die letzte Aktivität anzeigen. (Wann es das letzte Mal in dieser Umfrage teilgenommen wurde)

das ist die letzte (diesbezügliche) Aktivität irgend einen Users, der teilgenommen hat. Es ist nicht die letzte Aktivität der Umfrage :-)

Tabelle: Poll_Log
Also dann hier eine neue Spalte anlegen, wann an der Umfrage teilgenommen wurde.

Genau.

Da bräuchte ich dann evtl. ein INT-Feld noch in "t_Polls", ob die einzelne Umfrage zeitlich begrenzt ist oder nicht.

Wähle den Spaltentyp immer entsprechend des Datentyps, den Du speichern willst. Etwas, das schon im Namen "Datum" enthält, ist aller Wahrscheinlichkeit keine Zahl, sondern ein, nun, Datum. Welchen der vielen[1] Datumstypen Du wählst, hängt von den Ansprüchen ab, die Du erfüllen willst.

Gäbe es eventuell noch gute Funktionen für ein schönes Umfragescript?

Eine "nerv mich nicht mehr mit den bescheuerten Umfragen"-Spalte in der User-Tabelle vielleicht :-)

Was haltet ihr eigentlich davon, wenn das Mitglied die Möglichkeit hat, sein abgegebenes Voting im Nachhinein zu ändern, wenn man sich doch anders entscheidet.

Das könnte von der Umfrage abhängen. Genau wie die Frage, ob User das derzeitige Zwischenergebnis bereits sehen können, nachdem (oder sogar bevor) sie abgestimmt haben.

Cheatah

[1] Oracle kommt komischerweise mit nur einem Datumstyp aus, mit dem das gleiche möglich ist.

[gottlieb]

Hi,

LstVoteDate klingt nicht nach etwas, das Teil der Umfrage ist ...
Die Spalte sollte eigentlich die letzte Aktivität anzeigen. (Wann es das letzte Mal in dieser Umfrage teilgenommen wurde)

das ist die letzte (diesbezügliche) Aktivität irgend einen Users, der teilgenommen hat. Es ist nicht die letzte Aktivität der Umfrage :-)

*gg*, ok :-)

Das könnte von der Umfrage abhängen. Genau wie die Frage, ob User das derzeitige Zwischenergebnis bereits sehen können, nachdem (oder sogar bevor) sie abgestimmt haben.

Das finde ich garnicht mal so schlecht, dass man das Ergebnis nur sieht, wenn man selber ein abgestimmt hat. So lässt man sich evtl nicht beeinflussen, wenn eine Möglichkeit dominiert.

[Dirk]

Hallo Gottlieb,

ich würde es genau so machen - allerdings andere Bezeichnungen wählen.

1.) Entweder alles deutsch oder englisch. Einen Mehrsprachenmix finde ich nicht sehr elegant. Ich selbst bevorzuge englische Bezeichner.

2.) Namen für Tabellen (und Sichten) immer im Plural.

3.) Entweder immer "underscore" verwenden oder nie.

4.) Präfixe verwenden (t_ := Table; v_ := View; sp_ := Stored Procedure; usw.)

So würde ich deine Datenbankstruktur wie folgt aufbauen:

t_Members

• MemberId (PK)
• ...

t_Polls

• PollId (PK)
• MemberId (FK => t_Members.MemberId)
• PollText
• CreateDate
• FirstVoteDate
• LastVoteDate

t_PollAnswers

• AnswerId (PK)
• PollId (FK => t_Polls.PollId)
• Answer

t_PollResults

• ResultId (PK)
• MemberId (FK => t_Members.MemberId)
• AnswerId (FK => t_PollAnswers.AnswerId)
• PollDate

[Cheatah]

Hi,

1.) Entweder alles deutsch oder englisch. Einen Mehrsprachenmix finde ich nicht sehr elegant. Ich selbst bevorzuge englische Bezeichner.

jepp, jepp und ich auch.

2.) Namen für Tabellen (und Sichten) immer im Plural.

Oder immer im Singular. Ich bevorzuge letzteres: Der Datensatz, den ich zu jeder Zeit betrachte, ist immer nur einer.

3.) Entweder immer "underscore" verwenden oder nie.

Jepp. Da SQL case-insensitive ist und es sich mehr als eingebürgert hat, SQL-bezügliche Bezeichner durchgehend groß und DB-Layout-bezügliche Bezeichner durchgehend klein zu schreiben, lautet das Votum pro Underscore.

4.) Präfixe verwenden (t_ := Table; v_ := View; sp_ := Stored Procedure; usw.)

Nope, das ist Quatsch. Nach meiner Erfahrung bringen Prefixes bei Dingen, deren Bedeutung man leicht aus dem Kontext erkennen kann, genau eines: überflüssige Tipparbeit. Ach ja, und Fehlerpotenzial. _Wenn_ man Prefixes verwendet, dann eher bei den Spalten: Beispielsweise kann man mit "ref_member" spezifizieren, dass es eine Referenz auf die member-Tabelle ist.

t_Members

• MemberId (PK)

Und ID-Spalten benötigen *nicht* den Namen der Tabelle. "id" reicht absolut aus. Es geht um die "member.id", nicht um "t_members.memberid".

Cheatah

[gottlieb]

Hi,

t_Members

• MemberId (PK)

Und ID-Spalten benötigen *nicht* den Namen der Tabelle. "id" reicht absolut aus. Es geht um die "member.id", nicht um "t_members.memberid".

Ich persönlich finde es eigentlich schon besser, pollid zu nehmen, anstatt nur id. Naher weiß man, mit welchen beiden Spalten man Joint.

_Polls

• PollId (PK) ----------
                         |
  t_PollAnswers          |
• AnswerId (PK) -------

Grüße

[gottlieb]

Uuups,

_Polls

• PollId (PK) ----------
                         |
  t_PollAnswers          |
• AnswerId (PK) -------

das sollte natürlich zweimal PollId heißen *gG*

[Ilja]

yo,

2.) Namen für Tabellen (und Sichten) immer im Plural.

Oder immer im Singular. Ich bevorzuge letzteres: Der Datensatz, den ich zu jeder Zeit betrachte, ist immer nur einer.

der standard ist die singular verwendung.

Jepp. Da SQL case-insensitive ist und es sich mehr als eingebürgert hat, SQL-bezügliche Bezeichner durchgehend groß und DB-Layout-bezügliche Bezeichner durchgehend klein zu schreiben, lautet das Votum pro Underscore.

wobei man darauf achten sollte, dass objektnamen nicht case-insensitive sind.

Ilja

[Sven Rautenberg]

Moin!

Und ID-Spalten benötigen *nicht* den Namen der Tabelle. "id" reicht absolut aus. Es geht um die "member.id", nicht um "t_members.memberid".

Gleiche Dinge sollten gleich heißen.

Wenn man die ID nicht nur aus Spaß, sondern als Fremdschlüssel in anderen Tabellen nutzt, dann bietet es sich geradezu zwingend an (zumindest in meiner bescheidenen MySQL-Welt), die ID trotz gleichlautenden Tabellennamens ausführlicher zu benennen - und in den anderen Tabellen dann logischerweise gleichlautend.

Vorteil: JOINs können USING (member_id) verwenden anstelle von ON member.id = whatever.member_id, wenn es darum geht, die FK-Verbindung zu nutzen. Diese Schreibweise bevorzuge ich.

- Sven Rautenberg

[Ilja]

yo,

Gleiche Dinge sollten gleich heißen.

diese aussage widerspricht ab dem, was du machst. ein priamry key ist was anderes als ein fremdschlüssel. ich will zum beispiel schnell nur anhand eines names erkennen können, ob es sich um einen PK oder einen FK handelt.

Ilja

[Chris©]

Hallo Ilja,

Gleiche Dinge sollten gleich heißen.

diese aussage widerspricht ab dem, was du machst. ein priamry key ist was anderes als ein fremdschlüssel. ich will zum beispiel schnell nur anhand eines names erkennen können, ob es sich um einen PK oder einen FK handelt.

Ich denke, dass man das aus dem Zusammenhang eindeutig erkennen kann.
In einer komplexeren Anweisung muss man dann ohnehin qualifizierte Bezeichner verwenden. Da hat man dann zwar einige Redundanz in der Namensgebung, aber angesichts der Unterstützung, die Entwicklungstools dafür geben, halte ich die für gerechtfertigt.

... where adresse.id_adresse = kunde.id_adresse ...

sagt ganz deutlich aus, dass der erste Schlüssel ein PK ist und der zweite keiner sein darf, wenn man die erwähntgen Regeln einhält. Außerdem steckt die Aussage drin, dass die Schlüssel sich beide auf die Tabelle Adresse beziehen.

LG
Chris©

[Ilja]

yo,

Ich denke, dass man das aus dem Zusammenhang eindeutig erkennen kann.

klar kann man das, aber warum indirekt über den tabellennamen, wenn ich es auch direkt machen kann ? primary keys sind was anderes als foreign keys, also würde ich das auch im namen kenntlich machen. ich bieg mir ja kein ast ab, ob ich nun:

adresse.id_adresse = kunde.id_adresse

oder

adresse.id_adresse = kunde.fk_adresse

schreibe. und wenn ich dann noch aliasnamen verwende, dann bleibt dir klarheit auf jeden fall erhalten.

a.id_adresse = k.fk_adresse

Ilja

[Sven Rautenberg]

Moin!

Gleiche Dinge sollten gleich heißen.

diese aussage widerspricht ab dem, was du machst. ein priamry key ist was anderes als ein fremdschlüssel. ich will zum beispiel schnell nur anhand eines names erkennen können, ob es sich um einen PK oder einen FK handelt.

Zumindest in MySQL sind IDs üblicherweise eine Art von INT-Zahlen.

Aus Performancegründen sollen Felder, die per JOIN zusammengeführt werden, identische Felddefinitionen haben.

Also hat eine ID sowohl in der PK-Tabelle, als auch in allen FK-Tabellen die gleiche Definition - inklusive des Namens. Es ist effektiv ja (für den gleichen Datensatz) die gleiche Zahl.

Ein PK ist eindeutig daran zu erkennen, dass er auf den Namen tabelle.tabelle_id hört. Jede Art von FK ist durch tabelle.anderetabelle_id eindeutig erkennbar.

- Sven Rautenberg

[Ilja]

yo Sven,

Zumindest in MySQL sind IDs üblicherweise eine Art von INT-Zahlen.

Aus Performancegründen sollen Felder, die per JOIN zusammengeführt werden, identische Felddefinitionen haben.

jetzt würfelst du ein wenig was durcheinander. unabhängig von der unterschiedlichen bezeichnung, die wir beide für fk verwenden würden, so sind wir uns darin einig, dass die datentypen des pk und des fk gleich sind. das ist aber vollkommen unabhängig voneinander. was die namensgebung einer spalte betrifft, orientiere ich mich niemals (jedenfalls ist mir noch kein fall bekannt geworden) an den datentyp, den ich dabei für die spalte verwende.

Also hat eine ID sowohl in der PK-Tabelle, als auch in allen FK-Tabellen die gleiche Definition - inklusive des Namens. Es ist effektiv ja (für den gleichen Datensatz) die gleiche Zahl.

der gleiche datensatz kann es schon mal nicht sein, schließlich steht der pk und der fk in verschiedenen tabellen (selbstreferenz ausgenommen, da sind es aber andere datensätze, sonst hat man ein rekursions-problem).

Ein PK ist eindeutig daran zu erkennen, dass er auf den Namen tabelle.tabelle_id hört. Jede Art von FK ist durch tabelle.anderetabelle_id eindeutig erkennbar.

habe es chris bereits geschrieben, warum sollte ich es implizit über den tabellennamen machen wollen, wnn ich es gleich von anfang an direkt über den spaltennamen machen kann ?

Ilja

[Chris©]

Hallo Ilja,

jetzt würfelst du ein wenig was durcheinander. [...]

Kennst Du das Schlüsselwort "Using"?

SELECT * FROM adresse LEFT JOIN kunde USING (id_adresse);

wäre ein gültiges Statement, dass der Optimizer von MySQL so liebend gerne sehen würde. Wie würdest Du das ausdrücken, wenn die Spalten unterschiedlich benannt wären, obwohl sie doch denselben Wert enthalten müssen, wenn die Integrität nicht gebrochen ist.

http://dev.mysql.com/doc/refman/5.0/en/join.html

Andere DBMS sehen das genauso, dafür habe ich leider aber keine Internetlinks auf passende Manualseiten. Es IST Standard, dass Spalten, die denselben Wert repräsentieren sollen, auch gleich benannt werden und denselben Typ bekommen!

Ich unterstütze daher Sven Rautenbergs Aussagen!

LG
Chris©

[Ilja]

yo,

1. die referentielle integrität wird nicht durch die gleichen namen der spalten gewährleitest. sie ist unabhängig von der namensgebung.

2. der optimierer sieht auch andere statements gerne und ist nicht für einen guten ausführungsplan auf das using angewiesen.

3. die spalte des foreign keys kann einen wert enthalten, der nicht in der primary key spalte enthalten sein kann, ohne das die referentielle integrität verletzt wäre.

und noch mal was grundsätzliches. es geht nicht darum zu sagen, man kann die spalten nicht gleich bennen. es ist eine entscheidung, die jeder selbst treffen muss. ich würde es nicht tun, weil es meiner meinung nach mehr vorteile hat, sie unterschiedlich zu bennenen und ich auf using verzichten kann, ohne benachteiligt zu sein. für mich ist eben eine fremdschlüssel etwas anderes als ein primary key.

Ilja

[Cheatah]

Hi,

Und ID-Spalten benötigen *nicht* den Namen der Tabelle. "id" reicht absolut aus. Es geht um die "member.id", nicht um "t_members.memberid".
Gleiche Dinge sollten gleich heißen.

also IDs beispielsweise "id" ;-)

Wenn man die ID nicht nur aus Spaß, sondern als Fremdschlüssel in anderen Tabellen nutzt, dann bietet es sich geradezu zwingend an (zumindest in meiner bescheidenen MySQL-Welt), die ID trotz gleichlautenden Tabellennamens ausführlicher zu benennen - und in den anderen Tabellen dann logischerweise gleichlautend.

Spätestens wenn man mit mehreren Tabellen in einem Statement arbeitet, sollte man grundsätzlich alle Spalten mit der entsprechenden Tabelle bezeichnen, also "tabelle.spalte". Ein "tabelle.tabellespalte" ergibt für mich nur mäßig Sinn. Darüber hinaus bricht das Schema bei Selbstreferenzen und Kreuztabellen, die mit mehreren Spalten die selbe Tabelle referenzieren.

Vorteil: JOINs können USING (member_id) verwenden anstelle von ON member.id = whatever.member_id, wenn es darum geht, die FK-Verbindung zu nutzen. Diese Schreibweise bevorzuge ich.

Ich bin im allgemeinen ein Verfechter von "explicit is better than implicit", so auch hier. Sofern der Ausführungsplan davon nicht betroffen ist, empfehle ich die Nennung der jeweiligen Tabellen und Spalten anstelle eines Hauches von Magie.

Cheatah

[Chris©]

Hallo Cheatah,

t_Members

• MemberId (PK)

Und ID-Spalten benötigen *nicht* den Namen der Tabelle. "id" reicht absolut aus. Es geht um die "member.id", nicht um "t_members.memberid".

Da stimme ich nicht zu.
Hier sollte ein Präfix "ID_" oder "id_" vor dem Tabellennamen stehen, also z.B.

id\_adresse

Steht diese leicht als Schlüssel erkennbare Spalte an erster Stelle, ist sie Primärschlüssel der eigenen Tabelle, steht sie an späterer Stelle, ist sie Fremdschlüssel zur bezeichneten Tabelle.

Manche Systeme unterstützen in ihren Entwurfstools diese strikte Einhaltung einfachster Regeln, indem sie Beziehungen automatisch erkennen und vorschlagen/einrichten. Das spart viel Arbeit.
Außerdem sorgt es für eine ganz klare Übersicht.

LG
Chris©

[Cheatah]

Hi,

Und ID-Spalten benötigen *nicht* den Namen der Tabelle. "id" reicht absolut aus. Es geht um die "member.id", nicht um "t_members.memberid".
Da stimme ich nicht zu.
Hier sollte ein Präfix "ID_" oder "id_" vor dem Tabellennamen stehen, also z.B.
  id\_adresse

wenn der PK aus mehreren Spalten zusammengesetzt ist, mag ich dem zustimmen - abgesehen davon, dass der Tabellenname in keiner einzigen Spalte der selben Tabelle etwas verloren hat. (Bei Selbstreferenzen vertrete ich die selbe Meinung, votiere aber nicht gegen eine anderslautende.) Es gäbe dann also beispielsweise "tabelle.id_teil1" und "tabelle.id_teil2". Wenn man konsequent sein und dies auf einspaltige PKs übertragen möchte, empfiehlt sich ein anderes Prefix, z.B. "pk": "tabelle.pk_id".

Steht diese leicht als Schlüssel erkennbare Spalte an erster Stelle,

Die Reihenfolge der Spalten ist in der Nutzung eines Datenbankschemas nicht sichtbar. Dieses Argument kann also nur bei rein akademischen Betrachtungen eine Rolle spielen; in der Praxis ist es bedeutungslos.

Manche Systeme unterstützen in ihren Entwurfstools diese strikte Einhaltung einfachster Regeln, indem sie Beziehungen automatisch erkennen und vorschlagen/einrichten. Das spart viel Arbeit.

Mit solchen Tools habe ich entweder noch nicht gearbeitet, oder aber die von mir genannten Regeln ("id" für PKs, "ref_tabelle" für FKs) sind genauso einfachst.

Außerdem sorgt es für eine ganz klare Übersicht.

Was natürlich von der eigenen Gewöhnung abhängt.

Cheatah

[gottlieb]

Hi Dirk,

ich würde es genau so machen - allerdings andere Bezeichnungen wählen.

Vielen Dank. Ich bin dann wohl auf dem guten Weg, die Struktur der DB ordnungsgemäß (und evtl. normalisiert) zu gestalten :-)

1.) Entweder alles deutsch oder englisch. Einen Mehrsprachenmix finde ich nicht sehr elegant. Ich selbst bevorzuge englische Bezeichner.

Ja, ich mache dann alles naher auf Deutsch.

2.) Namen für Tabellen (und Sichten) immer im Plural.

Ja stimmt. Da ja mehrere Polls und Members in den einzelnen Tabellen sind.

Übrigens, nochmals vielen Dank für das ausführliche Posting.
Grüße

[gottlieb]

Hallo nochmals,
ich gebe ja den PK beim anlegen dr Tabelle mit PRIMARY KEY (Feldname) ein.
Muss man den FK auch explizit angeben? Wenn ja wie?

Grüße

mySQL > 5.0.1x