nicht angemeldet
Gleiche Datensätze lieber in 2 versch. Tabellen?
Hi!
Ich frage mich gerade was mehr Sinn macht:
Ich brauche sowas wie z.B. Gästebuch hosting .. ganz normale Tabelle
ID | Date | Entry usw.
Für alle Domains sollen jetzt Gästebücher instanziert werden und die Daten sollen so gespeichert werden.
Lege ich für jede Domain eine Tabelle an, oder soll ich lieber einer Tabelle ein Domain-Attribut spendieren, welches ich mit der Domain oder ner DomainID fülle?
Also lieber ganz viele Datensätze in einer Tabelle oder lieber ein wenig mehr Ordnung innerhalb der Tabelle, dafür dann aber wieder mehr Tabellen in der DB?
Vielen Dank schon mal :)
Bye, Transmitter
-
yo,
ich würde es in diesem falle trennen, also mehrere tabellen. zwar handelt es sich um gleiche entitäten, aber sie stehen in keiner verbindung miteinander, ausser dass sie alle von dir verwaltet werden müssen.
Ilja
-
ich würde es in diesem falle trennen, also mehrere tabellen.
Das Problem dabei wäre nur, dass es evtl. 10 Tabellen werden können pro Domain ..
Und somit kommen pro Domain auch immer 10 Tabellen hinzu, ich rechne vorerst mal mit 20 Domains, da wären wir schon bei 200 Tabellen, aber an Domains kann da echt noch mehr kommen ..Ist es dann immer noch sinnvoll es zu trennen?
-
yo,
das kommt meiner meinung stark auf dich selbst an, weil das trennen mehr aufwand für die verwaltung bedeutet, aber dafür für den Benutzer einen performance gewinn bedeuten kann, jenachdem wieviele datensätze letztlich in den tabellen stehen werden.
wenn es nur sehr wenige Datensätze sind, sollte man es vielleicht bei 10 tabellen pro domain nicht trennen. bei zig-tausenden macht es schon mehr sinn. wie gesagt, ich würde es trennen, da die gästebücher der einzelnen domains in keiner beziehung miteinander stehen.
Ilja
-
das kommt meiner meinung stark auf dich selbst an, weil das trennen mehr aufwand für die verwaltung bedeutet, aber dafür für den Benutzer einen performance gewinn bedeuten kann, jenachdem wieviele datensätze letztlich in den tabellen stehen werden.
wenn es nur sehr wenige Datensätze sind, sollte man es vielleicht bei 10 tabellen pro domain nicht trennen. bei zig-tausenden macht es schon mehr sinn. wie gesagt, ich würde es trennen, da die gästebücher der einzelnen domains in keiner beziehung miteinander stehen.
Das ist schon richtig .. die haben nichts miteinander zu tun, irgendwie wäre es mir doch lieber, die alle in eine zu packen, wenn da nicht wirklich irgendwas MySQL spezifisches dagegen spricht.
Hmm .. ich lese mir gerade mal was bei MySQL selbst durch:
Für alle Gästebücher in einer Tabelle:
http://www.mysql.com/doc/de/Table_cache.html-
Hi,
Das ist schon richtig .. die haben nichts miteinander zu tun, irgendwie wäre es mir doch lieber, die alle in eine zu packen, wenn da nicht wirklich irgendwas MySQL spezifisches dagegen spricht.
doch, die haben etwas miteinander zu tun. Die sind in einer Datenhaltung und sind "eine Entitaet". (Performanceueberlegungen sind ermal sekundaer.)
IMHO - eine Tabelle!
Gruss,
Lude---
"Die Forumsteilnehmer hier kann man auch alle in eine Tabelle packen."-
yo,
nicht alles was sich gleicht, hat etwas miteinander zu tun. normalisierung ist eine gute sache, aber es gibt gründe bei bestimmten kriterien wieder zu denormalisieren.
ich würde sogar einen schritt weiter gehen und für jede domäne eine eigene datenbank einrichten. das ist für das backup und recovery schon von vorteil. fällt eine datenbank aus, sind nicht gleich alle gästebücher aller domäins down.
Ilja
-
Hi,
nicht alles was sich gleicht, hat etwas miteinander zu tun. normalisierung ist eine gute sache, aber es gibt gründe bei bestimmten kriterien wieder zu denormalisieren.
ist es nicht _ein_ Gaestebuchserver?
ich würde sogar einen schritt weiter gehen und für jede domäne eine eigene datenbank einrichten. das ist für das backup und recovery schon von vorteil. fällt eine datenbank aus, sind nicht gleich alle gästebücher aller domäins down.
Stell Dir mal vor die Sache ist(wird) erfolgreich. Dann sollte man doch den Administrationsaufwand moeglichst klein halten.
Gruss,
Lude---
"Alles so einfach wie moeglich. (Aber nicht einfacher ;-)."-
ist es nicht _ein_ Gaestebuchserver?
Nicht nur, aber im Prinzip ist es vergleichbar.
ich würde sogar einen schritt weiter gehen und für jede domäne eine eigene datenbank einrichten. das ist für das backup und recovery schon von vorteil. fällt eine datenbank aus, sind nicht gleich alle gästebücher aller domäins down.
Das wäre mir sogar auch noch lieber, aber leider habe ich nur ca. 1 - 3 DB´s zur verfügung, ein eigener Server ist erst mal noch nicht drin :(
Stell Dir mal vor die Sache ist(wird) erfolgreich. Dann sollte man doch den Administrationsaufwand moeglichst klein halten.
Und das wiederrum geht wohl mit einer Tabelle am besten, stimmt auf jeden Fall :)
-
Ilja
Stell Dir mal vor die Sache ist(wird) erfolgreich. Dann sollte man doch den Administrationsaufwand moeglichst klein halten.
Und das wiederrum geht wohl mit einer Tabelle am besten, stimmt auf jeden Fall :)
jeder muss das selbst entscheiden, ich würde es in tabellen teilen weil:
a) die performance dadurch verbessert wird, da es deutlich weniger datensätze pro tabelle gibt und die indexe nicht über alle bestehenden gästebücher aufgebaut werden.
b) die ausfallsicherheit verbessert wird. ist eine tabelle beschädigt, fallen alle anderen gästebücher nicht aus.
c) die gästebücher zwar die gleichen eigenschaften besitzen, aber nicht weiter miteinander in verbindung stehen. datenbanken, bzw. tabellen enthalten nur alle nötigen und nicht alle möglichen daten.
d) backup and recovery schneller gehen, man muss nicht alle gästebücher zusammen sichern und wieder einspielen und kann dies auf unterschiedliche zeiten verteilen.
e) der adminstrative aufwand der gleiche ist, ob es sich nun um eine gemeinsame tabelle handelt oder um mehrere, da die struktur der tabellen identisch ist. lediglich der namen der tabelle muss man ändern und selbst diesen prozess kann man automatisieren.
Ilja
-
Hi,
a) die performance dadurch verbessert wird, da es deutlich weniger datensätze pro tabelle gibt und die indexe nicht über alle bestehenden gästebücher aufgebaut werden.
Performanceueberlegungen hatte ich zurueckgestellt, spielen aber bei der geschilderten Anforderungslage eine untergeordenete Bedeutung.
b) die ausfallsicherheit verbessert wird. ist eine tabelle beschädigt, fallen alle anderen gästebücher nicht aus.
Datentabellen gehen normalerweise nicht kaputt. Aber selbst, wenn die kaputtgehen, muss man nur einen Job einrichten, der beispielsweise stuendlich die Konsistenz der Datenbank checkt und im Fehlerfall besipielsweise eine Mail sendet.
c) die gästebücher zwar die gleichen eigenschaften besitzen, aber nicht weiter miteinander in verbindung stehen. datenbanken, bzw. tabellen enthalten nur alle nötigen und nicht alle möglichen daten.
Die Gaestebuecher stehen logisch miteinander in Verbindung.
d) backup and recovery schneller gehen, man muss nicht alle gästebücher zusammen sichern und wieder einspielen und kann dies auf unterschiedliche zeiten verteilen.
Das Backup geht schneller bei einer DB, das Recovern eigentlich auch.
e) der adminstrative aufwand der gleiche ist, ob es sich nun um eine gemeinsame tabelle handelt oder um mehrere, da die struktur der tabellen identisch ist. lediglich der namen der tabelle muss man ändern und selbst diesen prozess kann man automatisieren.
Auch Widerspruch, ausserdem will man vielleicht ja auch die Datenhaltung mal weiterentwickeln.
Nein, klarer Fall: eine DB
Gruss,
Lude-
yo,
wenn etwas beschädigt wird ist es nie der normalfall. der vorteil ist, fällt eine tabelle aus, laufen die anderen noch.
Die Gaestebuecher stehen logisch miteinander in Verbindung.
und welche logik wäre das, die hier eine rolle spielt ?
Das Backup geht schneller bei einer DB, das Recovern eigentlich auch.
nein, das sehe ich anders. wenn ich 10 mal soviele daten zu sichern habe, geht es nicht schneller.
Auch Widerspruch, ausserdem will man vielleicht ja auch die Datenhaltung mal weiterentwickeln.
und welcher widerspruch.
Nein, klarer Fall: eine DB
wir reden erstens von tabellen und zweitens ist das ansichstsache udn nicht klar. letztlich muss er entscheiden.
Ilja
-
Hello Ilja,
wenn etwas beschädigt wird ist es nie der normalfall. der vorteil ist, fällt eine tabelle aus, laufen die anderen noch.
Die Gaestebuecher stehen logisch miteinander in Verbindung.
und welche logik wäre das, die hier eine rolle spielt ?
Das Backup geht schneller bei einer DB, das Recovern eigentlich auch.
nein, das sehe ich anders. wenn ich 10 mal soviele daten zu sichern habe, geht es nicht schneller.
Auch Widerspruch, ausserdem will man vielleicht ja auch die Datenhaltung mal weiterentwickeln.
und welcher widerspruch.
Nein, klarer Fall: eine DB
wir reden erstens von tabellen und zweitens ist das ansichstsache udn nicht klar. letztlich muss er entscheiden.
Stimme Dir da wohl (soweit ich das im Moment überblicken kann) voll zu. Und die API hat ja auch nix mit den Datenbanken zu tun. Die kann man polyporph entwickeln (hier ist dann mal include() angebracht). Wnn sich an den Tabellen was ändern muss, repariert das die API in 0,08 Sekunden automatisch beim nächsten Call (Request), wenn sie denn intelligent geschreiben ist. Alle Formate sind zentral gespeichert und können durch lokale überschrieben werden (ganz so wie bei CSS) und das Funktioniet dann sogar.
Und Widerspruch nehem ich nur von Leuten an, die mit "include" auch seeehr vorsichtig umgehen.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen -
Hi,
Die Gaestebuecher stehen logisch miteinander in Verbindung.
und welche logik wäre das, die hier eine rolle spielt ?
die der Realitaet, die wir versuchen nachzubilden.
wir reden erstens von tabellen und zweitens ist das ansichstsache udn nicht klar. letztlich muss er entscheiden.
Richtig, es ist Ansichtssache. Klar, dass wir beide sicher sind Recht zu haben. Waere ja auch traurig, wenn's nicht so waere. ;-)
Gruss,
Lude---
"Permanente Kleinschreibung bringt individuellen Zeitgewinn und allgemeinen Zeitverlust."-
yo,
und welche logik wäre das, die hier eine rolle spielt ?
die der Realitaet, die wir versuchen nachzubilden.
das tun wir nur bedinkt, den unsere rechenleistung reicht bei weiten nicht für die realität aus, zumal wir die realität nur beschränkt kennen.
deshalb bilden wir in einer datenbank nicht die realität ab, sondern alle notwendigen daten, um ein ausreichendes modell der realität abzubilden. die realität ist sicherlich ein vorbild, aber was wir machen ist ein modell.
und deshalb ist es sinnvoll, nicht alles was man kann reinzunehmen, sondern was man braucht. und die daten eines gästebuch braucht nicht die daten des anderen gästebuch, nur weil sie die gleichen attribute besitzen. oder mit anderen worten, wenn ich eine mitarbeiter tabelle für eine firma erstelle, werde ich keine datensätze von mitarbeiter einer anderen firma mit einnehmen, nur weil sie die gleichen attribute haben.
Ilja
-
Hi,
die der Realitaet, die wir versuchen nachzubilden.
das tun wir nur bedinkt, den unsere rechenleistung reicht bei weiten nicht für die realität aus, zumal wir die realität nur beschränkt kennen.
darum kam auch das Wort 'versuchen' zur Anwendung. (BTW - die Realitaet kennt uns.)
deshalb bilden wir in einer datenbank nicht die realität ab, sondern alle notwendigen daten, um ein ausreichendes modell der realität abzubilden. die realität ist sicherlich ein vorbild, aber was wir machen ist ein modell.
Sehr treffend formuliert, danke.
und deshalb ist es sinnvoll, nicht alles was man kann reinzunehmen, sondern was man braucht. und die daten eines gästebuch braucht nicht die daten des anderen gästebuch, nur weil sie die gleichen attribute besitzen. oder mit anderen worten, wenn ich eine mitarbeiter tabelle für eine firma erstelle, werde ich keine datensätze von mitarbeiter einer anderen firma mit einnehmen, nur weil sie die gleichen attribute haben.
Ich hab' aber schon gesagt gehabt, dass ich eine andere Meinung habe. Quiek.
Gruss,
Lude---
"Die Realitaet ist das, was uebrig bleibt, wenn man aufgehoert hat zu glauben."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Hi,
Ich frage mich gerade was mehr Sinn macht:
Keines von beiden - es könnte aber eine der Varianten mehr Sinn _haben_.
Ich brauche sowas wie z.B. Gästebuch hosting .. ganz normale Tabelle
ID | Date | Entry usw.
Für alle Domains sollen jetzt Gästebücher instanziert werden und die Daten sollen so gespeichert werden.
Lege ich für jede Domain eine Tabelle an, oder soll ich lieber einer Tabelle ein Domain-Attribut spendieren, welches ich mit der Domain oder ner DomainID fülle?Wer hat alles direkten Zugriff auf die Datenbank?
Wenn jeder der Domain-Inhaber Zugriff hat, dann MUSST Du für jeden eine eigene Datenbank (mit eigenem User/Paßwort) bauen, schon aus Datenschutz-/Datensicherheits-Gründen, denn sonst könnte ja jeder der Domain-Inhaber Zugriff auf ALLE Datensätze ALLER Gästebücher haben.
cu,
Andreas--
MudGuard? Siehe http://www.mud-guard.de/-
Wer hat alles direkten Zugriff auf die Datenbank?
Ich bin der einzige, der darauf Zugriff hat, evtl. noch mal ein Mitarbeiter, aber alle anderen bekommen ein Webinterface.
Also muss ich mich nicht um die Berechtigungen auf MySQL Ebene kümmern :)
Mir geht es wirklich nur darum, ob es besser ist 200 Tabellen zu haben oder lieber 30 mit dementsprechend mehr Datensätzen.
Habe gerade das hier:
http://www.mysql.com/doc/de/Table_cache.html
gelesen ... also lieber alle GB´s in eine Tabelle .. ?Oder spricht da was dagegen?
Bye, Transmitter
-
yo,
Wenn jeder der Domain-Inhaber Zugriff hat, dann MUSST Du für jeden eine eigene Datenbank (mit eigenem User/Paßwort) bauen, schon aus Datenschutz-/Datensicherheits-Gründen, denn sonst könnte ja jeder der Domain-Inhaber Zugriff auf ALLE Datensätze ALLER Gästebücher haben.
ich würde ihm auch jeweils eine datenbank pro domäne empfehlen. dies ist aber kein muss, sondern in meinen augen die beste option. selbst wenn die daten in einer tabelle stehen, hat noch lange nicht jeder zugriff auf die gesamte tabelle.
Ilja
-
-
Hello,
das wird bestimmt auch von der Sicherheit und Funktionstüchtigkeit Deines Webinterfaces abhängen. Wenn zum Beispiel konkurrierender Betrieb nicht anständig berücksichtigt wird, kann es schon mal vorkommen, dass die Daten gestört werden oder sogar alle weg sind.
Dann wäre es doch besser, es sind nur die Daten von einer Domain weg und nicht alle, oder?
Zu Deinen Bedenken mit den offenen Tabellen:
Die werden auch nicht alle gelichzeitig offen sein, wenn Du sie in unterschiedlichen Datenbanken anlegst. Die Connection zur Datenbank ist ja immer nur sehr kurz vorhanden, danach sind auch die Table-Buffer wieder frei.Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen