einzeltabellen vs riesentabelle

[voelkerballtier]

angenommen ich habe eine tabelle mit usern und möchte nun zu jedem user produkte speichern (1:n), macht es (performance-mäßig) sinn, für jeden user eine produkttabelle anzulegen oder einfach alle produkte in eine tabelle und per userID zuordnen

Nebeninfos:
Ich rede hier von (produkt)tabellen im GB bereich
Es werden keine Joins zwischen den Tabellen benötigt (sprich sowas wie gib alle produkte von A und B)
Wenn ich eine große Produkttabelle mache, wüde ich sozusagen JEDE abfrage auf userID joinen

ja ich hab leider zu wenig ahnung von datenbanken - rein aus intuition würd ich alles in eine tabelle packen - datenbanken sind schließlich dafür da joins schnell auszuführen - wenn einzeltabellen in dem fall jedoch performancevorteile bringen könnten dann halt damit

€ achso, datenbanktyp steht noch net fest, nehmt erstmal MySQL an

 

[FiShy_inaktiv]

Mach ne n:m Beziehung draus.

Mach eine UserTabelle
eine Produkttabelle
und eine Beziehungtabelle also UserID und ProduktID

So sagt es zumindestens die Theorie und die dritte Normalform einer Datenbank

 

[voelkerballtier]

Edit: ne jedes produkt hat einen user als besitzer - eine zusätzliche beziehungstabelle ist also nicht nötig

 

[RRA^StArFiRe]

was verstehst du denn unter einzeltabellen?
meinst wahrscheinlich, die produkte als nichtatomare attribute mit in die usertabelle schreiben?
also:

User(!userID, name,..., {Produkte})
Produkte(!id, ....)
?

macht in der hinsicht sinn, wenn du im weiteren verlauf nicht mehr auf die produkte bzw auf deren attribute zugreifen musst und sich produkte nicht ändern.

im allgemeinfall macht mans aber wie fishy schon sagte. dritte normalform:
User(!userID, name...)
Produkte(!id, ...)
Bestellt(!bestellID, userID, id, datum...)

oder meintest du eine ganz andere möglichkeit?
naja, die erste möglichkeit würde performance später in der ausgabe bringen, wenn du nur die produktinformationen ausgeben willst, die auch wirklich da reingeschrieben wurden. vor allem sollten sich die produktwerte nicht bzw nicht häufig ändern. denn bei der ersten variante haste viel zu tun, bei änderung oder löschen eines produkts, jede spalte bei den usern zu updaten.

aber normalerweise macht mans in der dritten normalform.


btw "schnelle joins" bekommste später eh, wenn du vor dem join die einträge mitm select filterst.

 

[voelkerballtier]

nein mit einzeltabellen meine ich für jeden user eine produkttabelle mit seinen produkten a la Produkte_UserID, in der man dann natürlich kein Feld UserID mehr braucht da diese ja durch den Tabellennamen fest ist

 

[RRA^StArFiRe]

öhm... kA wie du auf die idee gekommen bist, aber so gehts auf keinen fall.

kann man überhaupt zur laufzeit create table ausführen?
das war doch quasi n admincommand?

 

[killerchicken_inaktiv]

Wie viele User sollen das werden? Wenn du von vielen Usern redest, mach auf keinen Fall pro User eine Tabelle, denn das zieht gerade MySQL sehr runter (auch wenn du auf die Normalform verzichten willst, was selten ne wirklich gute Idee ist). Denn generell wirst du dann ein riesiges Problem bekommen, wenn du zB. den Artikelnamen in den Produkte_userid-tables gespeichert hast, und dann aendert sich der Produktname - Alptraum. Also mach eine Tabelle mit allen Produkten, eine mit allen Usern, und eine die die beiden tables verbindet, fertig

 

[voelkerballtier]

Original geschrieben von killerchicken
Wie viele User sollen das werden? Wenn du von vielen Usern redest, mach auf keinen Fall pro User eine Tabelle, denn das zieht gerade MySQL sehr runter (auch wenn du auf die Normalform verzichten willst, was selten ne wirklich gute Idee ist). Denn generell wirst du dann ein riesiges Problem bekommen, wenn du zB. den Artikelnamen in den Produkte_userid-tables gespeichert hast, und dann aendert sich der Produktname - Alptraum. Also mach eine Tabelle mit allen Produkten, eine mit allen Usern, und eine die die beiden tables verbindet, fertig

"wollen" tu ich das nicht - ich frage nur ob es uU sinnvoll sein kann

#user ~ 100
#produkte/user ~ 100,000

frage ist: 100 tabellen mit jeweils 100,000 einträgen oder eine mit 10,000,000

uahh ich merk grad ihr habt mich total wuschig gemacht 8[

also jedes produkt hat natürlich nur EINEN user als besitzer, es ist also wie ich anfangs schrieb eine 1:n relation - SORRY für das hin und her -_-

 

[killerchicken_inaktiv]

Wie erm Produkte sind unique? Also kein Produkt gehoert mehr als einem Besitzer?

 

[RRA^StArFiRe]

also hast ne 1:n relation?
dh ein user hat mehrere produkte, und ein produkt hat genau einen user.

User(!UID, ...)
Product(!PID, ..., UID)

bei egal wievielen usern brauchst (um auf deine 100.000 beziehungen zwischen user und product zu kommen) folglich auch 100.000 produkte.

du willst das optimieren, indem du die beiden tabellen zusammenziehst?

Userproduct(!(UID, PID), ...)

quasi mit einem zusammengesetzten primärschlüssel. damit gehst du nicht über die erste normalform hinaus.
kannste machen, aber bringt dir einiges an mehraufwand, wenn du die daten des Users oder des Produkts ändern willst.
denn um zb ein attribut zu ändern, was nur vom User (UID) funktional abhängig ist, musst du alle zeilen mit der UID anfassen. in der dritten normalform brauchste dazu nur in der Usertabelle einen eintrag ändern.
fürs Produkt dürfte das egal sein, da das Produkt eh nur in einer Spalte vorkommt.

ich frag mich allerdings immer noch, wie du dir das mit den 100 tabellen vorgestellt hast, entweder haste 2 tabellen oder eine.
und wenn du 100 tabellen dynamisch erzeugst, was soll da drinstehn?

 

[xornado]

zu jedem user eine tabelle würde natürlich die zuordnung produkt-->user über eine extre user_id-spalte überflüssig machen, gleichzeitig aber auch jegliche datenbankänderungen etc. verkomplizieren.

was killerchicken gesagt hat kommt da noch am besten
user-tabelle mit id,name
produkttabelle mit id, name
und ne zuordnungstabelle

leider kenne ich mich in solchen dimensionien null aus:

was wäre, wenn die daten in der "großen" tabelle in einem string gespeichert werden [z.b. immer 5000 produkte pro user] und dann als array ausgelesen werden ? würde ja eigentlich die datenbank etwas auf kosten der php (?)-rechenzeit entlasten .... [bitte korrigieren falls falsch]

 

[killerchicken_inaktiv]

Original geschrieben von xornado
zu jedem user eine tabelle würde natürlich die zuordnung produkt-->user über eine extre user_id-spalte überflüssig machen, gleichzeitig aber auch jegliche datenbankänderungen etc. verkomplizieren.

was killerchicken gesagt hat kommt da noch am besten
user-tabelle mit id,name
produkttabelle mit id, name
und ne zuordnungstabelle

leider kenne ich mich in solchen dimensionien null aus:

was wäre, wenn die daten in der "großen" tabelle in einem string gespeichert werden [z.b. immer 5000 produkte pro user] und dann als array ausgelesen werden ? würde ja eigentlich die datenbank etwas auf kosten der php (?)-rechenzeit entlasten .... [bitte korrigieren falls falsch]

@xornando: Das letzte was du gesagt hast ist total falsch, sowas darf man niemals machen. _JEDER_ eintrag in der Datenbank kommt in ein eigenes Feld, ansonsten stell dir mal vor du willst das 4356ste Produkt des users xy aendern - hf damit

Zudem bin ich davon ausgegangen, dass Produkte nicht unique sind - wenn sies naemlich sind, braucht man das nicht so wie ichs geschrieben habe...

Ansonsten, wenn es wirklich 10,000,000 Produkte sind, die alle verschieden sind, kann man dafuer auch pro Kunde eine Tabelle anlegen, wenn man tatsaechlich keine Uebersicht ueber die ganzen Produkte etc braucht. Was hier fehlt ist einfach ne genauere Beschreibung der Anforderungen - also genau das, woran die allermeisten Projekte scheitern, weil die Anforderungen nicht genau bestimmt werden. Erzaehl doch mal ganz haarklein, was das werden soll bitte

 

[xornado]

ja, ich habs eben mal ausprobiert:


$asdf = mysql_fetch_array()
...$testarray = explore($asdf[blah],"<trennzeichen>");
foreach ($testarray as.....)

da lacht die rechenzeit wirklich nicht
deshalb stürzt auch immer mein selbstgeschriebener md5hash-decoder ab

 

[EnimaN]

die imo entscheidende frage ist, ob du jemals eine aktion für mehrere benutzer machen musst - dann solltest du wohl nur 2 tabellen benutzen.

wenn es allerdings wirklich auf keinen fall vorkommt und du 100%ig immer nur an einem benutzer arbeitest, bringen mehr tabellen wohl einen performance schub - allerdings hast du einen größeren verwaltungsaufwand und es ist komplizierter die struktur konsistent zu halten.

 

[voelkerballtier]

hrm k - danke david und v.a. killerchicken

es soll wirklich keine funktionen wie gesamtproduktsuche oder sonstige user-uebergreifende datensichten geben und wenn doch dann nur als seltene ausnahmen und dann muss ich halt ueber 100 tabellen joinen...