Login

#1 (**permalink**) 19-01-2010, 12:02

Hi,

was wäre bei folgendem Problem besser, 2 Tabellen anlegen oder alles in eine Tabelle?

Es gibt verschiedene Tarife, die liegen alle in einer Tabelle mit ihren speziellen Daten. Nun kommen noch Daten hinzu, die zwar auch zu jedem Tarif zugeordnet werden, aber eher nur dazu gedacht sind bei einer Bestellung alles richtig zuzuordnen. Im Prinzip ist es ja eine 1:1 Beziehung.

Die zweite Tabelle wäre ja dann sowas wie:
key | foreign_key (Tariftabelle) | spalte1 | spalte2

#2 (**permalink**) 19-01-2010, 14:32

Hallo,

ab diesem Satz verstehe ich nichts mehr:

Zitat:

Zitat von lx-club

Nun kommen noch Daten hinzu, die zwar auch zu jedem Tarif zugeordnet werden, aber eher nur dazu gedacht sind bei einer Bestellung alles richtig zuzuordnen.

Was für Daten? Wie sehen die aus? Warum ist es eine 1:1-Beziehung und nichts anderes? Sollte ein Tarif nicht den Zweck erfüllen, eine wiederverwendbare Preisstruktur zu schaffen? Wo ist die Wiederverwendbarkeit bei einer 1:1-Beziehung?

Kannst du darauf bitte noch eingehen und generell etwas weiter ausholen, grade im Bezug auf die Logik/Semantik dahinter?

Gruß,

Amica

#3 (**permalink**) 19-01-2010, 20:32

ok, also ich mein sowas wie z.B. eine Usertabelle. Dort stehen name, passwort, email drin. Jeder User kann aber auch en Profil haben. Dort steht dann ein Willkommenstext, Hobbys usw.

Es gibt also eine Tabelle User und eine Profil. Die Tabelle Profil hat als Fremdschlüssel die User-ID. Das ist ja auch ne 1:1 Beziehung und in 2 Tabellen aufgeteilt, genauso ist es mit den Tarifen.

#4 (**permalink**) 19-01-2010, 20:46

Faustformel:
1:1 Beziehungen passen in 1 Tabelle
1:n Beziehungen brauchen 2 Tabellen
n:m Beziehungen brauchen 3 Tabellen

Die 5 Normal Formen

#5 (**permalink**) 19-01-2010, 20:53

Ok, also ist bei dir eine Tabelle der Tarif. Was steht denn in der anderen drin? Bis jetzt sehe ich keine Notwendigkeit oder Logik, das aufzuteilen.

Wie combie schon sagte... Die einzige sinnvolle Ausnahme ist für mich so ein Fall.

#6 (**permalink**) 19-01-2010, 21:10

hi,

ich werde es dann alles in eine Tabelle machen. War mir ja selber nicht sicher und deswegen hier mal nachgefragt. :-)

Dann würde also mein Beispiel mit der User- und Profiltabelle auch nur eine Tabelle werden.

#7 (**permalink**) 19-01-2010, 21:21

Erstell doch einfach mal die Tabelle so wie du es für richtig hälst und stell sie dann hier rein.

Oder noch besser, nen Screenshot mit 3-4 Demodaten. Daran sollte schon erkennbar sein, ob es richtig ist oder nicht.

#8 (**permalink**) 19-01-2010, 21:54

Hi,

ich bin eigentlich dadurch drauf gekommen... DB-Modell s. unten in dem gelblichen Feld wo "User" steht

dort ist das besipiel mit den usern und ich wollte es bei mir auf die tarife übertragen.

#9 (**permalink**) 19-01-2010, 22:09

Warum die das de normalisiert haben, kann man ohne Insider Kenntnisse nicht sagen.

#10 (**permalink**) 19-01-2010, 22:15

Ich würde das ja ganz anders machen.

Du hast in einer Tabelle alle User.
In einer weiteren Tabelle definierst du Profil-Felder. Also Hobby, etc.
In einer m:n Tabelle kannst du die Felder mit den Usern verbinden und die Felder durch den User füllen lassen. Ein User muss dabei auch nicht alle Profilfelder nutzen.

#11 (**permalink**) 20-01-2010, 17:35

Was ist eigenltich der Vorteil an deiner Methode? (Werde sowas demnächst auch benötigen)
Davon abgesehen find ich es gar nicht schlecht. :-) So erscheint mir die Trennung dann wieder logisch :-)

#12 (**permalink**) 20-01-2010, 17:45

Zitat:

Zitat von lx-club

Was ist eigenltich der Vorteil an deiner Methode?

Wenn du den Beitrag von Abraxax meinst: Es ist normalisiert und erlaubt (wie er schon sagte), dass man nicht alle Felder angeben muss. Außerdem kannst du später einfach ein neues Profilfeld in der DB einfügen, an das du anfangs vielleicht nicht gedacht hast und das ohne etwas an der Struktur zu ändern.

Gruß,

Amica