MYSQL ... Was ist besser...

Original von 4future
Folgendes: Ich baue eine Gallerie, in die in absehbarer Zukunft 100.000 Bilder in 1000 Gallerien erscheinen könnten. Nun hab ich mich bei der Menge gefragt: Lege ich eine Tabelle so an:

ID NAME KATHEGORIE_ID COUNTER

Oder leg ich automatisch für jede neue Kathegorie eine Tabelle in etwa so an:

ID NAME COUNTER

und eine Tabelle in der alle Kathegorieren drin sind.

---------------------------
Noch was wär für mich interresant,
Wie würdet ihr es machen wenn es sagen wir mal 10.000 Bilder währern oder anders, wo sind die Grenzen von einem MYSQL Server ? bei wieviel Tabellen oder Datensätzen in einer Tabelle ????

bzw. wäre es für den User ertragbar (wartezeiten) wenn mysql 100.000 nach ca. 30 Datensätzen durchsucht ?

Schau dir doch nochmal die Normalisierungsformen an. Du würdest garnicht Bsp.:ID, Kategorie und Bild alles in einer Tabelle tun können, weil du dich entscheiden mußt, was abhängig von der ID sein soll. Weil in einer Kategorie gibt es ja mehrere Bilder und wenn schon die Kategorie die ID verpasst bekommen hat, kannst du sie auch nicht dem Bild geben. Das würde sonst ein Datenbankcrash geben.
Deswegen ist es ja auch sinnvoller eine Datenbank mit mehreren Tabellen zu basteln. Deine andere Idee, mit der Extratabelle, wo nur die Kategorien angelegt sind und jede Kategorie nochmal eine Tabelle hat, wo die Bilder aufgelistet werden, würde gehen.
 
Jungs ich will ja mal nix sagen, aber ihr verwirrt mich mittlerweile !
 
ne ich bin kein azubi mehr... und ich weiß auch was die normalisierung ist..

aber die normalisierung ist eigentlich gar nicht meinem problem ...
ich weiß gar nicht was du damit hast...

was mein problem ist:
die entitätsmengen, also die ich nenn sie jetzt mal so die realen objekte werden ja normalerweise in eine tabelle gesteckt. also alle bilder in eine tabelle, und du suchst dir an hand eines feldes (hier: kathegorie) die bilder aus, die in der aktuellen kathegorie angezeigt werden...

Da kam mir die Idee, ich könnte die ladezeiten ja beschleunigen, indem ich für jede kathegorie eine tabelle anlege, in der die bilder drin sind, da muss dann nichts gesucht werden... dann würde eine suchfunktion über eine tabelle vorhandene_kathegorien immer noch realisierbar sein .... wär dann zwar langsamer, aber eine gallerie is ja in erster linie zum anzeigen da...

da ich aber wie gesagt fisy bin, und eigentlich nichts mit db's zu tun habe, wollt ich wissen was besser ist... und statt hier rumzusimpeln hätt ich gern eine sinnvolle antwort... und das wird langsam echt verwirrend... der großteil sagt ganz sicher eine tabelle, und ein paar sagen felsenfest eine tabelle.

um der ganzen sache jetzt einmal ein ende zu setzen, ein db-admin aus meinem laden meint das das eigentlich in eine tabelle gehört... und das mach ich jetzt auch, ihr könnt gerne weiterdiskutieren, was besser ist, ich klink mich jetzt hier aus... viel spass...
 
Ich würde dir "felsenfest" zu mehreren Tabellen raten, zumal da du auch Daten besser ordnen und auflisten, sowie filtern kannst.
Das alles nur in einer Tabelle zu stecken, wäre meiner Meinung nach unpraktisch und würde zu vielen Fehlern führen.
Wenn du deine Datenbank erweitern willst, müßtest du auch meistens die ganze Datenbank wieder auf den Kopf stellen und neuaufbauen. Der Grund ist die Normalisierungsform, die nicht umsonst für Datenbankprogrammierer aufgestellt wurde, um zu einer funktionierende Datenbank zu verhelfen.
Aber am Ende ist es deine Entscheidung, was du machst und niemand, ebenos wenig wie ich will dir vorschreiben was du nutzen sollst.
 
Mein Vorschlag:

Einfach einen Benchmark für die Varianten machen. Dann wird man es schon sehen.
Zudem sind interne Umsetzungsprozeduren bei allen Datenbanksystemen anders.
D.h. die gleich Abfrage ist in Oracle vielleicht viel schneller, eine andere in MYSQL.
Sinvoll sind auf jeden Fall Cluster, um Daten redundant zu halten auf mehreren Systemen.

Ich weiss aus erfahrung nur, dass die typische 100% normaliserte DB bei grossen Datenmengen in jedem Geschwindigkeitswettbewerb verliert.
 
Zurück
Oben