• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Datenbankdesign

Status
Für weitere Antworten geschlossen.

stoni

Neues Mitglied
guten Morgen,
ich hätte da mal eine Frage zum Datenbanklayout - evtl könnt ihr mir ja den einen oder anderen Tipp geben. Ich bastel momentan am Layout für eine SQL-Datenbank die eine Art Community verwalten soll. Das ganze ist nicht unbedingt ernst zu nehmen sondern dient erst einmal mehr der Übung. Bei den meissten Sachen bin ich mir eigentlich sicher das ich eine für meine Anforderungen passende Lösung gefunden habe. Lediglich bei einem bin ich mir unsicher.
Wie es bei solchen Seiten nun einmal so ist muss ich Benutzer verwalten. So ein Benutzer hat die verschiedensten Eigenschaften/Attribute - wie ihr es auch immer nennen wollt. Das fängt ja ganz trivial an mit einer ID einem Namen, Nick persönliche Angaben... usw. mittlerweile kann ich in der zugehörigen Tabelle Benutzer fast 30 Felder vergeben.
Nun meine Frage: Wie organisiere ich so einen Benutzer am geschicktesten? Nehme ich eine Tabelle und packe da alles hinein, verpasse der Tabelle evtl noch einige Indices damit ich nach bestimmten Kriterien schnell suchen kann?
Oder mache ich einfach aus der einen großen Tabelle 2 Tabellen - die erste mit der eigentlichen ID und den für die meissten Seiten intresannten Werten wie Nick, onlinestatus benutzerbild... und die andere Tabelle hält den Rest vor der hauptsächlich auf einer Profilseite angezeigt werden würde.

Von der reinen Geschwindigkeit her würde ich vermuten das ich mit der ersten Variante am schnellsten eine komplette Profilseite aus der Datenbank abrufen kann. Bringt mir die 2. Variante geschwindigkeitsvorteile wenn ich ein kleines Forum einbauen würde? Da wären ja nicht alle Profildaten erforderlich - sondern nur ein paar aus der kleineren Tabelle.
Allerdings muss ich ja in beiden Fällen für gewöhnlich die Benutzerdaten anhand einer ID suchen - da würde die Breite der Tabelle ja keine Rolle spielen, oder?

Wie ihr wahrscheinlich gemerkt habt bin ich recht unentschlossen und leicht verwirrt. Vielleicht kann mir ja mal der eine oder Andere nen Hinweis geben? Vielleicht gibts ja auch Lösungen an die ich noch nicht gedacht habe?

nu aber erst mal jute nacht...
 
Genau das selbe "Problem" habe ich auch... :mrgreen: Wenn da jemand was zu sagen kann, wäre es super.
 
Genau das selbe "Problem" habe ich auch... :mrgreen: Wenn da jemand was zu sagen kann, wäre es super.

Das ist eigentlich Grundlage von Db Entwicklung.Man muß sich entscheiden welche Normalisierungsform stufe man anwenden möchte.

Aufteilungen macht man meisten nur wenn man Redunazen vermeiden möchte was dann wiederum zur Performec beiträgt sowie auch dann komplexere abfragen möglich werden.

Wenn man eine Aufteilung auf eine andere Tabele macht muß man sich immer überlegen zu welcher Beziehung stehen diesen beiden Elemente und genauso muß man achten das es eine eindeutigkeit gibt.

Wenn du viele sachen hast wo andere das auch haben dann kanst du eine 1/n Beziehung machen.

Wie jetzt das genau zu lösen ist in der Obigen frage kann man so nicht beantworten weil einfach zuviele details informationen fehlen.

Mfg Splasch
 
hi - also um die Datenbank zu erstellen benutze ich erst mal MySQL Workbench. Ich habs vorher noch nicht ausprobiert - aber es scheint alles zu unterstützen was ich benötige - hauptsächlich einen Export um die Tabellen erstellen zu lassen aber auch views usw... bei den einzelnen Abfragen könnte TOAD mir auch helfen wenn ich das richtig verstanden habe? Ich werd's mir morgen mal ansehen

Wie jetzt das genau zu lösen ist in der Obigen frage kann man so nicht beantworten weil einfach zuviele details informationen fehlen.

Mfg Splasch

Warum sagst du das denn nicht schon eher? Was für Informationen fehlen dir noch? Ich dachte eigentlich ich wäre recht ausführlich gewesen...

Ich stelle meine Frage mal etwas allgemeiner:
Ergeben sich Nachteile für mich dadurch das eine Tabelle in meiner Datenbank viele Felder benötigt? Die Breite so einer Tabelle ist doch theoretisch für meine Geschwindigkeit bei Abfragen irrelevant, oder? Leider geht es mir nicht um reine Datenbankabfragen - ich werde einige Sachen des öfteren updaten müssen (onlinestatus). Wenn ich der Tabelle nun auch noch den einen oder anderen Index verpasse befürchte ich das das nicht die geschickteste Variante ist...
 
Warum sagst du das denn nicht schon eher? Was für Informationen fehlen dir noch? Ich dachte eigentlich ich wäre recht ausführlich gewesen...

Weil so eine Datenbank Planung sehr umfangreich ist und es zu müsham were alles immer wieder nachzufragen.

Ergeben sich Nachteile für mich dadurch das eine Tabelle in meiner Datenbank viele Felder benötigt? Die Breite so einer Tabelle ist doch theoretisch für meine Geschwindigkeit bei Abfragen irrelevant, oder?

Theoretisch hast du nur deswegen keine Geschwindigkeit einbusen aber viele Nachteile die dann zu Geschwindigkeits einbussen führen können und zwar genau dann wenn du dadurch viele Redunazen zusammen bekommst.
Und abfragen nur durch Umwege mehr möglich sind wenn überhaupt dann noch.

Bsp.
Angenohmen du würdes keine Normalisierung machen und alles in ein Tabelle werfen was ja möglich ist aber auch falsch

Du hast User und nachrichten von User um nun alle Nachrichten eines User abzufragen müßtes du dann einen sehr umständlichen sql befehl schreiben.

Resultat Performenc sehr langsam
Weitere Nachteile bei komplexeren sachen kann man garnicht mehr das Ergebniss abfragen weil man in einer sackgasse landet.

Nun hätte man bei der Planung schon entscheiden müssen das nachrichten und User getrennt gehören und in welcher Beziehung diese zu einander stehen.

Das selbe gilt für dein Beispiel da ich aber nicht weiß was alles nun in der Tabelle stehen soll kann ich dir nur ein ähnliches Beispiel nennen.

zb.
Die User haben ein Profil wo sie auswählen können ob sie skype,irc,icq unsw verwenden.
Hierbei kann man davon ausgehen das es mehre User geben wird die icq verwenden und auch mehre die skype verwenden.

Dadurch haben wir wenn wir das in einer Tabelle machen würden eine Redunaz. Dort würde dann zum beispiel 40 mal skype ,80 icq stehen.

Um das zu vermeiden bestimmen wir eine Beziehung zwischen user und den (skype,icq,irc unsw.)
Da es mehrer User gibt aber nur 1 mal den namen skype oder icq oder irc kommt nur eine 1/n Beziehung in frage was bedeuted wir brauchen eine 2 Tabelle in der wir die sachen wie skype,irc,icq unsw. eintragen und eine spalte mit einer eindeutigkeit dafür können wir einen integer spalte mit autoincrement verwenden.
In der User tabelle brauchen wir daher nur mehr die Beziehung eintragen als Fremdkey mit einen integer feld der den Wert an gibt.

Genau so gehst du das mit allen durch und entscheidest wo es sin macht und wo du eher darauf verzichten kanst.

Mfg Splasch
 
Ok du hast natürlich Recht - was die Angaben angeht war ich wirklich ungenau. Also es soll die Möglichkeit geben Nachrichten und ähnliches untereinander zu Verteilen. Das alles hat aber nach meinem Verständnis sowieso nichts in der Tabelle für einen Benutzer zu suchen (wie du auch schon geschrieben hast). Da ein Benutzer ja n Nachrichten an verschiedene Benutzer schicken kann habe ich solche Sachen direkt in eine seperate Tabelle ausgelagert. Über die ID der einzelnen Benutzer kann dann der entprechende Benutzer herausgefischt werden. In der eigentlichen Tabelle für einen Benutzer habe ich lediglich vorgesehen:

name
zuname
onlinestatus
userbild
nick
passwordhash
mail
[eine Unmenge Mehr Felder für persönliche angaben]

zusätzlich zu den ganzen persönlichen Angaben noch ein bis zwei Felder in die ich vorhabe mit der benutzten Skriptsprache Inhalte zwischenzuspeichern (ich befürchte php-arrays oder ähnliches)

Da ich ja auf so einer Communityseite zwangsläufig andauernd auf die Tabelle Benutzer zugreifen muss (alles hängt nun mal von Benutzern ab) gehe ich davon aus das ich wenn ich diese Tabelle nicht ordentlich durchdenke mir viele Probleme vor allem was die Performance angeht einhandel (sowas würde man auch erst wirklich merken wenn man auch die Idee kommt das ganze mal in der Realität zu testen)

Die meissten Daten in dieser Tabelle sind Private Angaben die man auf einem Profil wiedergeben würde -um die mache ich mir keine großen Sorgen- auch sollten Redundanzen wie in dem von dir angesprochenen Beispiel mit IM- Messengern nicht auftreten bei der Art von Daten.

Momentan überlege ich eher wie es mit der Performance ausschaut wenn ich in der großen Tabelle dynamische Inhalte wie einen Onlinestatus ändere. Solange ich keinen Index auf dem Feld Onlinestatus gebildet habe sollte ein update auf die Tabelle relativ schnell erfolgen, richtig? Das sollte auch unabhängig von der Breite der Tabelle sein, oder gibt es für Daten die sich des öfteren ändern eine bessere Lösung die ich nicht kenne?

Ich vermute ich müsste um alle Unklarheiten zu beseitigen erst mal mein komplettes Layout fertigmachen und posten - damit wir hier nicht theoretisch weiter um den heissen Brei herumreden müssen. Trotzdem schon einmal vielen Dank für die Mühe die du dir mit mir gemacht hast.
 
Performance ist ein Breites Thema angefangen von dem Tabellen type denn man verwendet bis hin über views. Wie man die sql befehle schreibt und vieles mehr.

Mit dem können sich Profis monate lang beschäftigen um eine optimale leistung rauszuholen.

Solange ich keinen Index auf dem Feld Onlinestatus gebildet habe sollte ein update auf die Tabelle relativ schnell erfolgen, richtig?

Also meine information ist anders wenst du einen index auf eine Spalte setzt kanst du damit sogar bessere performenc erreichen weill er dann beim durchsuchen der Tabelle schneller ist und net alles durchsuchen muß, ist auch bei update so da ja in where klause gesucht wird bei insert wird wohl gleich bleiben.
Dabei muß man jetzt aber denken das es nicht sinvoll ist auf jedes feld einen index zu setzen dann were der Vorteil von index weg.
siehe auch dazu unter:
infos24 mysql > mysql Setzen von Indexen

Aber da gibst noch soviele andere sachen zum Thema Datenbank Perfomec.
Die lassen da extra eigene db Benschmark drüber laufen um zu testen welche startegie die beste für diese eine Datenbank ist.

Mfg Splasch
 
[...]
Also meine information ist anders wenst du einen index auf eine Spalte setzt kanst du damit sogar bessere performenc erreichen weill er dann beim durchsuchen der Tabelle schneller ist und net alles durchsuchen muß, ist auch bei update so da ja in where klause gesucht wird bei insert wird wohl gleich bleiben.
[...]
auch da habe ich mich nicht deutlich ausgedrückt - meine Überlegung war folgende: Wenn ich einen Index auf eine Spalte setzte beschleunige ich ja die Suche die ich über diese Spalte ausführe. Wenn ich jetzt aber eine Zeile in die Tabelle einfüge müssen alle Indices die ich in der Tabelle erstellt habe ein update erfahren (damit jeder Index wieder sortiert ist) - das ist ja nicht weiter schlimm da ich für gewöhnlich wesentlich öfter eine Abfrage aus einer Datenbank mache als ich Daten einfüge. Auch werde ich nicht wahllos auf alle Spalten einen Index legen sondern nur auf Spalten nach denen ich des öfteren eine Abfrage generieren werde. Und das auch nur dann wenn es Werte gibt die es lohnt zu indizieren - wenn es ein Spalte für ein Geschlecht geben würde wäre das herzlich unsinnig darauf auch noch einen Index zu legen, oder halt mein oninestatus.
Wenn ich nun also keinen Index auf die Spalte für den Onlinestatus gelegt habe und ich den Oninestatus für einen Benutzer in der Datenbank ändere wird die Datenbank nicht hingehen und alle Indices neu erstellen - das wäre halt eine Sache die mein ganzes System ziemlich ausbremsen würde. Hoffentlich hab ichs nu ordentlich erklärt....
 
Die Spalte oninestatus ist dabei bedeutunglos es kommt nur im endefeckt dann drauf an wie der Sql befehl aufgebaut ist.

Wenn auf der User id ein index ist und in der selben Tabelle auch der oninestatus gespeichert wird dann wirst du bei einen update in der Wehre klausel nach der User id suchen und damit ist die Änderung schneller als were kein index gesetzt worden.(Im grunde kommt es drauf an nach was du am häufigsten suchen wirst)

Wo du den index setzt muß man induell Testen am besten über benschmark um das beste Ergebniss zu erziehlen.
Lies dir auch oben den link durch da steht einiges darüber.

Mfg Splasch
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben