Floid

Hallo Community!

Ich frage mich schon seit einiger Zeit ob es Sinn macht Felder einer Tabelle welche man normalerweise nur sehr selten braucht oder nur in speziellen Abfragen relevant sind in eine weitere Tabelle auszulagern. Diese Tabelle stellt eine 1:1 Beziehung mit der ersten Tabelle dar.

z.B.

id user1_id user2_id status accepted_at rejected_at

friendship_id request_at request_text

Fett: Primary Key

Gibt es Fälle indem es Sinn macht ? GRUND dafür?

Danke schonmal für die Informationen!

Mister Ad

mepeisen

Das kommt immer drauf an, wo du bei der Normalisierung den Schnitt ansetzt. Ist ein Benutzer nur durch seinen Benutzernamen definiert? Gehört die ICQ-Adresse zum User direkt dazu oder ist das eine zusätzliche Entität?

Aus praktischen Gesichtspunkten ist das relativ unerheblich, solange du nicht mit SELECT * arbeitest, was natürlich bei ganz vielen Datenfeldern auch viele holt, duie du gar nicht brauchst in einer Abfrage. Je nach Datenbanksystem macht es jedoch aus Performance-Sicht Sinn, insbesondere TEXT und BLOB Felder auszulagern, da diese meist auch in der Datenbank eine variable Größe haben und somit beim Zugriff auf Datensätze eventuell die Performance verschlechtern, selbst wenn du sie nicht selektierst.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Floid

Also ich verwende MySQL. und SELECT * verwende ich nicht.

Aber mein Anschlag hatte ich auch bei der Theorie mit der Performance oder Skalierbarkeit.

So hätte ich die wichtigsten ~10 Informationen welche ich an den User binden möchte in der User Tabelle direkt. Eine zweite Tabelle namens "user_about" z.b. könnte die grosse Menge an Zusatzfelder welche man wirklich nicht grad immer braucht auslagern.

Für alles andere gibt es ja noch den Innerjoin

So meine These. Ich frage jetzt genau wegen dem die Datenbank Experten hier!

mepeisen

Performance ist im Regelfall unerheblich bei konstanten Feldgrößen. Daher muss man die nicht zwangsläufig trennen. Auch eine Tabelle mit 40 Feldern bricht in der Performance nicht zwangsläufig ein, wenn die Felder selbst konstant groß sind (Ints, CHAR). Erst wenn Blobs und Texts hinzu kommen, wird manches DB-System langsamer. Ob spürbar oder nicht, kann ich dir nicht verraten. Auf jeden Fall brauchst du bei 40 oder 50 Feldern und 1000 Datensätzen solche Überlegungen auch nicht anstellen.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Floid

okhei danke ich verstehe !

nun bei meinem obrigem beispiel ist es aber ja so das ein friendship_request nur einmal bei der freundschaftsanfrage benötigt wird. später werden felder wie request_at und request_text ja sowieso nie mehr benötigt.

wie siehts aus mit dem Grund ? könnte man schon gelten lassen oder

mepeisen

Es gibt keine eindeutige Antwort darauf.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

rodger

Hallo, genau diese Frage interessiert mich auch grade sehr. Auch genau die Situation, wenn man die Daten die man nun auslagern oder beibehalten will, nur an einer bestimmten Stelle braucht. Ich denke mir, das es ja eigentlich nicht schaden kann, das dann auszulagern, bzw es schadet ja auch der Installation nicht wirklich, wenn nun eine zusätzliche Tabelle vorhanden ist, denke ich mir jedenfalls mal. Ich würde sagen, meinem derzeitigen Kenntnisstand entsprechend tendiere ich eher dazu, die Felder - es sind drei Felder - auszulagern.

Gruß, Rodger

jGeee

Das hängt alles von sehr vielen faktoren ab. Ich selbst habe in einem großen Redaktionssystem (mittlerweile 12.000 Artikel) die Tabellen ebenfalls gesplittet, auch aus Performance gründen.

article_infos = Titel, PublishUpTimestamp, PublishDownTimestamp, Redakteurinfos, Views, usw.
article_content = Nur der Inhalt des Artikels
article_teaser = Nur die Teaser

Bei der Anzahl an Datensätzen, vorallem wegen der Größe der einzelnen Artikel, macht das imho schon sinn, jedoch hängt es nicht nur von der DB ab, auch Server inkl. der Hardware spielt ja zudem eine große Rolle...

rodger

Was meinst du damit? meinst du das es Server gibt, bei denen es mehr sinn macht Felder in neue Tabellen auszulagern und Server bei denen es mit der gleichen Seite/software mehr sinn macht die Felder in einer größeren Tabelle zu behalten?

Gruß, Rodger

thomas_w

Vertikale Partitionierung von Tabellen kann schon sinnvoll sein, speziell wenn einige Spalten sehr häufig und
andere selten benötigt werden und/oder sehr groß sind (z.B. BLOB, TEXT etc.).

Eine Beispieltabelle, bei der Spalten die "oft" und "selten" verwendet werden, könnte so aussehen. Es existiert eine 1 zu 1 Verknüpfung des PRIMARY KEY.

Mit Hilfe einer VIEW kann dann (optional) eine Gesamttabelle nachgebildet werden. Geht natürlich auch mit einem normalen JOIN.


Das Auftrennen verbessert die Lesegeschwindigkeit, wenn nur eine Tabelle (also nur ein Teil der Daten) gelesen werden muss.
Daten in so eine "Tabelle" einfügen, ändern oder löschen kann komplizierter werden, wenn erst geprüft werden muss, welche Tabelle (oder beide Tabellen) betroffen sind. Beim Löschen hilft natürlich ein FOREIGN KEY mit ON DELETE CASCADE.

Die Datenbank-Parameter (MySQL) auf dem Server (my.ini), sowie verfügbarer RAM, die IO-Geschwindigkeit der Platten etc. haben einen großen Einfluss auf die Geschwindigkeit.

Grüße
Thomas