Funktionale Einheiten aufteilen
0 
Manuel B.
0 0
Funktionale Einheiten aufteilen
Ich möchte in meinem aktuellen Projekt eine Funktionale Einheit mehrfach verwenden. Und zwar habe ich in PHP eine Seite geschrieben, in der man sich als Gruppe organisieren kann (Forum, Galerien, etc.). Jetzt sollen jedoch mehrere Gruppen ermöglicht werden. Daher frage ich mich, ob es sinnvoller ist, in mySQL für jede Gruppe eine eigene Datenbank anzulegen, in der die zur Gruppe gehörigen Daten in den Tabellen gespeichert werden, oder ob alles in einer Datenbank liegen sollte und dort die Tabellen um ein Feld wie zum Beispiel gruppen_id erweitert werden sollte. Welche Variante ist performanter und sinnvoller?
-
Ich grüsse den Cosmos,
Welche Variante ist performanter und sinnvoller?
Das kommt auf die Anzahl der Datensätze und Gruppen an.
Bei weniger als 500 Gruppen und weniger als 200.000 Datensätzen dürftes du bei keiner deiner Lösungen merkbare Unterschiede haben.Möge das "Self" mit euch sein
--
Neulich dachte ich mir, einmal S/M ausprobieren wäre eine tolle Erfahrung. Also hab ich Windows gebootet ...
ie:{ br:> fl:| va:| ls:& fo:{ rl:( n4:{ de:] ss:) ch:? js:| mo:) sh:( zu:) -
Ich möchte in meinem aktuellen Projekt eine Funktionale Einheit mehrfach verwenden. Und zwar habe ich in PHP eine Seite geschrieben, in der man sich als Gruppe organisieren kann (Forum, Galerien, etc.).
Du hast eine Nutzerverwaltung, Gruppen, Rechte, Sitzungen, "Inhalte" (Forum, Galerie etc.), gut.
Jetzt sollen jedoch mehrere Gruppen ermöglicht werden. Daher frage ich mich, ob es sinnvoller ist, in mySQL für jede Gruppe eine eigene Datenbank anzulegen, in der die zur Gruppe gehörigen Daten in den Tabellen gespeichert werden, oder ob alles in einer Datenbank liegen sollte und dort die Tabellen um ein Feld wie zum Beispiel gruppen_id erweitert werden sollte.
Nutzergruppen werden in Tabellen mit dem Namen "Nutzergruppen" gehalten, Nutzer in einer mit dem Namen "Nutzer", zusammengehörige Tabellen (Entitäten) werden in einer DB gehalten.
Es gilt der Satz, den schon der erste Kaiser kannte, "Divide et impera!"Welche Variante ist performanter und sinnvoller?
Die Realität verstehen und nachbauen, schau mal i.p. Theorie in der Wikipedia nach ERM. Stell auf jeden Fall den Performancegedanken zurück und komme nicht mit zu vielen DB-Objekten (und auch nicht zu wenigen ;).
-
Also wenn ich mir das von der Struktur her überlege, halte ich es für logisch, die Daten für jede Gruppe in eine separate Datenbank zu stecken, da ja eigentlich keine Verbindung zwischen den Gruppen besteht und somit keine Daten aus der Datenbank gewonnen werden müssen, die etwas mit mehreren Gruppen zu tun haben. Die Verbindung der Gruppen wird über eine weitere Datenbank hergestellt, in der die Nutzerangaben getrennt von den Gruppeninhalten gespeichert werden. Wie groß die Dimensionierung in ausfallen wird, kann ich noch nicht abschätzen... kommt darauf an, ob sich viele Leute anmelden, und dann wenige Gruppen gründen in denen sie viel schreiben oder viele Gruppen gründen, in denen sie dann jeweils weniger schreiben... aber gibt es denn von mySQL-Seite her irgendwelche Grenzwerte, bei denen die Performance zu leiden hat, was zum einen die Datenbankgröße und zum anderen die Datenbankanzahl angeht?
-
Also wenn ich mir das von der Struktur her überlege, halte ich es für logisch, die Daten für jede Gruppe in eine separate Datenbank zu stecken, da ja eigentlich keine Verbindung zwischen den Gruppen besteht und somit keine Daten aus der Datenbank gewonnen werden müssen, die etwas mit mehreren Gruppen zu tun haben.
Gruppen? Datenbanken sind für viele Gruppen da. Eine Datenbank ist eine Datenbasis, also ein Rudel von Tabellen, die zusammengehören und ERM-mässig (ruhig mal googeln was das ist) zusammengehören und verzeigert sind.
Die Verbindung der Gruppen wird über eine weitere Datenbank hergestellt, in der die Nutzerangaben getrennt von den Gruppeninhalten gespeichert werden.
Das liest sich so als ob alles schon da ist, was ist denn da?
Wie groß die Dimensionierung in ausfallen wird, kann ich noch nicht abschätzen... kommt darauf an, ob sich viele Leute anmelden, und dann wenige Gruppen gründen in denen sie viel schreiben oder viele Gruppen gründen, in denen sie dann jeweils weniger schreiben...
Sorry, aber diese Aussagen erregen meinäussersters Misstrauen bzgl. der korrekten Implementation der Datenhaltung.
aber gibt es denn von mySQL-Seite her irgendwelche Grenzwerte, bei denen die Performance zu leiden hat, was zum einen die Datenbankgröße und zum anderen die Datenbankanzahl angeht?
Die MySQL-Doku ( <www.mysql.de> ), Version beachten, kennst Du aber schon?
-
Nunja, soweit ich ERM verstehe, ist es nur ein Designvorschlag, um sich eine logische Datenstruktur zu schaffen, auf der aufbauend man seine Datenbank-Struktur entwickelt und keine exakte Vorgabe mit konkreten Regeln (oder ich habe es falsch verstanden). Dennoch beinhaltet sie ja die angesprochene Verzeigerung, die aber von Inhalten einer Gruppe zu Inhalten einer anderen Gruppe nicht gegeben ist, weshalb ich zu der Lösung mit mehreren Datenbanken tendiere.
Es besteht bereits eine Datenbank, die die Inhalte, also Forenbeiträge, in die Galerien eingefügt Bilder und was es sonst noch an Daten innerhalb einer Gruppe gibt, hält. Da zum Zeitpunkt dieser Entwicklung noch keine Erweiterung auf mehrere Gruppen vorgesehen war, ist dieser Teil bereits fertig und funktionsfähig. Um nun von einer Gruppe zu mehreren zu kommen, habe ich zusätzlich zu dieser Gruppensoftware eine Portalseite geschrieben, in der man sich ein übergeordnetes Konto anlegen kann und einzelnen Gruppen beitreten/welche gründen kann. Und da die beiden von mir genannten Lösungswege, mehrere Gruppen zu integrieren keinerlei Einfluss auf Datenredundanz haben, sondern nur die Frage betreffen, ob eine riesige Tabelle die z.B. sowohl die Foreneinträge aus Gruppe 1, als auch aus Gruppe 2 enthält, auf die Dauer (also ist wahrscheinlich mit großen Datenmengen zu rechnen) die bessere Lösung für eine Strukturierung ist, oder mehrere Datenbanken sinnvoller sind.
Die MySQL Doku habe ich heute nachmittag ebenfalls bemüht, jedoch nichts gefunden, was mir bei dieser Entscheidung bislang weitergeholfen hat.
-
Nunja, soweit ich ERM verstehe, ist es nur ein Designvorschlag, um sich eine logische Datenstruktur zu schaffen, auf der aufbauend man seine Datenbank-Struktur entwickelt und keine exakte Vorgabe mit konkreten Regeln (oder ich habe es falsch verstanden).
Für mich ist es zwingend. Die Realität bzw. die zu implementierende Geschäftslogik bedingt ein bestimmtes Datendesign.
Dennoch beinhaltet sie ja die angesprochene Verzeigerung, die aber von Inhalten einer Gruppe zu Inhalten einer anderen Gruppe nicht gegeben ist, weshalb ich zu der Lösung mit mehreren Datenbanken tendiere.
:(
[...]
Ein Problem ist auch, dass wenn Du mit mehreren DBs kommst, wenn nur eine DB erforderlich ist, dass Du Dich möglicherweise grundsätzlich nicht dem Einfachheitsgebot der IT verpflichtet fühlst.
-
Also sollte ich besser alles in einer DB machen und ein Feld mit der Gruppenzugehörigkeit einfügen?
-
Also sollte ich besser alles in einer DB machen und ein Feld mit der Gruppenzugehörigkeit einfügen?
Sicher. Und Du solltest nicht nur die Anzahl der DBs, sondern auch die der Tabellen und auch aller anderen Objekte möglichst gering halten.
-
Ok, dann werd ich das mal so umsetzen... was die Tabellen angeht, nehme ich an, dass die möglichst gering gehalten sind, da sie ja in Normalform gebracht sind... bestend Dank für die Hilfe!
-
-
-
-
-
-