jo abend ersma,

ich bin etwas unsicher zur zeit wie das ist, ob die Anzahl von Tabellen pro Datenbank irgendwelche Auswirkungen auf die Performance hat. In der Doku von Mysql steht auch noch dass es Overhead erzeugen würde. Allerdings hab ich diesen Artikel da nich so ganz verstanden. Vielleich kann mir das mal einer erleutern.

Zur zeut hab ich 29 Tabelle inner DB und ich brauch jetzt noch 3 mehr. Und deswegen würde ich gerne sichergehen dass das auch keine Konsequenzen hat.

Ich danke für hilfe

jut nacht =)

Bild Blog <--

der overhead dürfte sich darauf beziehen, dass für die zusätzlichen tabellen infos über die struktur gespeichert werden müssen. wenn überhaupt merkst du davon aber nur bei sehr vielen tabellen überhaupt etwas. (die performance hängt hauptsächlich davon ab, wie du auf die db zugreifst. wenn du 100 überflüssige queries hast, ist das natürlich langsamer.)

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

Meister, ich kenne relationale Datenbanken mit über 250 Tabellen und mehr. Und da geht es auch flott zur Sache. Kommt natürlich immer auf den Contenttype an. Wenn du da lauter Blobs drinhast, wird es natürlich selbst für einen leeten Server schonmal eng, wenn da auf einmal 1000 Anfragen sind oder so. Aber 32 Tabellen... lächerlich :)

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

jut dann kann ich die DBs ja vollhaun
vielen dank =)

Bild Blog <--

nur nicht all zu grosszügig rate ich

das ist egal - mit deinen winzigen webapplikationen kommst du niemals an die designgrenzen von mysql.
Nur solltest du nicht zu viele Tabellen erstellen, weil du sie ja dann alle auch irgenwann abfragen musst, was dann schon ein wenig braucht ;)

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren

das ist egal - ich meinte eigentlich von grund auf sauber zu arbeiten is besser
trotzdem danke dass du meinen post verstanden hast

du solltest soviele tabellen machen, wie nötig sind für deine anforderungen. wenn du z.b. alles in der 3. nf machen willst (was generell eine gute idee ist für kleinere web apps), dann brauchst du eben soviele wie dafür nötig sind. der dadurch entstehende overhead ist auf jeden fall zu vernachlässigen, was plattenplatz betrifft sowieso, was query performance betrifft ebenfalls. denn das zahlt sich dadurch aus, dass du eine _relativ_ konstante performance hast bei beliebiger datenmenge.

Eins unserer DB2-Systeme hier hat auch mit 36.785 Tabellen noch keine Probleme :)) Aber wir haben dieses Jahr auch wieder für über 100 Mio. $ Hardware bestellt ...

Aber wie schon gesagt sind 30 Tabellen für ein MySQL-System noch keine nennenswerte Menge. Kommt eher auf das Design und die Zugriffe an

jo thx schon für die Hilfe

hab jetz nur noch ne Fage:
Was für Merkmale hat denn ein gutes Design von ner DB?
Und welche Zugriffe sind denn betroffen von der Datenmenge?

Bild Blog <--

Zitat:

SEeEL postete
Was für Merkmale hat denn ein gutes Design von ner DB?

z.B. http://ffm.junetz.de/members/reeg/DSP/node6.html

Es geht vorallem darum Redundanzen zu vermeiden und noch anderes.

-=[ Aigu.ch ]=-

Ähm ja - wenn du das gelesen hast und es auch verstehst (ich hätte es wohl nicht vestanden, wenn ich nicht mit Datenbanken umgehen könnte ;), weist eigentlich so ziemlich alles.

Aber die Aussage "keine Redundanz" ist nicht als ultimativ gültig zu verstehen - Du solltest Redundanz vermeiden, aber manchmal bringt sie mehr Geschwindigkeitsvorteile, als sie Nachteile bringt.
Im dort gezeigten Beispiel natürlich nicht ^^. In einem Forum wie z.B. dem wbb wird der benutzername auch bei jedem Post gespeichert, obwohl dort ja schon die benutzerid liegt, womit man ja den Namen aus der benutzertabelle holen könnte.
Jedoch wäre dafür bei fast jedem Seitenaufruf an dieser Stelle ein JOIN von nöten, dass sonst keinen Nutzen hat. Da die Benutzernamen doch eher selten geändert werden, ist der Aufwand, der dann zum Ändern jedes Eintrags nötig ist, auch akzeptabel. In solche Ausnahmefällen ist Redundanz also durchaus akzeptabel.

Was du natürlich bei der Planung deiner Datenbank genauso wie beim der Restlichen Planung nicht vergessen solltest, ist die Erweiterbarkeit. Du solltest dir gut überlegen, ob du das Ganze nicht eventuell später erweitern willst, und was dann wohl noch dazu soll.
Wenn du das vergisst, wrd es später eventuell ziemlch ärgerlich ;)

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren

mal abgeshen davon, dass das wbb ein denkbar schlechtes beispiel ist, weil es nämlich arschlahm ist. beim thwb ist der name btw _nicht_ bei jedem post gespeichert.

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

Bist du nicht der meinung, dass besonders bei wachsender Datenbank der geschwindigkeitsgewinn duch diese Maßnahme nicht von der Hand zu weisen ist?

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren

nein. da das query zunächst sowieso ohne join verarbeitet wird, entsteht lediglich der minimalaufwand zusätzlich, dass einige usertable-records per primary key (also ein unique index) selected werden müssen - und das ist sehr schnell wie du sicher zustimmen wirst.

auch wenn benutzernamen selten geändert werden, ist das noch kein argument. fakt ist, dass benutzernamen geändert werden. ganz nebenbei (um jetzt mal bei diesem beispiel zu bleiben) ist es so auch sehr einfach, zusätzliche userdaten wie postanzahl, titel, wohnort abzurufen. das sind nämlich spalten, die sich sehr oft ändern und auch in älteren posts aktuell sein sollten.

klar, sobald man mehr als den Benutzernamen braucht, macht das keinen Sinn mehr.

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren

Der Benutzername wird in manchen Foren ja nur deshalb mitgespeichert, damit beim Löschen eines Benutzers, trotzdem noch ersichtlich ist, von wem der Post stammt.
Da muss eben bei vielen Benutzern in jedem Post der Benutzername mitgespeichert werden.
Genaue Abfragen über den Benutzer, laufen dann eh über die ID des Benutzers, welche in jedem Post mitgespeichert wird.
-> normalisieren soweits geht.

Rambo Engineer @ Drippy's 2fort - finest TFC 1.5 || Bild Upload || The world's most advanced open source database

als ich das letzte mal den thwb source angeschaut habe, war das db design noch weit von vernünftigen nf's entfernt...

because our freedom sits at the end of a gun
we're all here getting beat up and held back
we're all here digging knives from our backs

hat ja auch keiner gegenteiliges behauptet ;)