Daten auf zwei Tabellen splitten nur wegen Tabellengröße?

[Friedward74]

Mein Problem ist folgendes ich habe neben diversen anderen Tabellen EINE Tabelle mit vielen (100) Spalten und Daten zu meinen Usern. Hier gibt es auch einige Textfelder für die Selbstbeschreibung, die rege genutzt werden und die Tabelle deutlich vergrößern.

Macht es Eurer Meinung nach aus Performancegründen bei Selektionen auf die nichtindizierten Nicht-Textfelder Sinn, die Textfelder aus dieser 1:1 Beziehung in eine zweite Tabelle auszulagern, auf der wiederum dann eine Volltextsuche auf die Textfelder läuft? Oder sollte man wenn es geht immer alle Daten eines Datensatzes / Users in einer Tabelle halten?

Immerhin müßte ich bei der Abfrage eines User-Profils dann immer zwei Tabellen abfragen. Zur Zeit ist das über eine Tabelle natürlich einfacher.

[asp2php]

was ... 100 Spalten für eine User-Tabelle was speicherst du denn alles darein? auf jeden Fall sollst du mal über den DB-Design nachdenken

[Friedward74]

Das mache ich ja gerade (naja, hundert sind´s noch nicht ganz, aber es werden zur Zeit eher mehr als weniger)

Gespeichert werden dort vor allem Eigenschaften und Antworten der User zu Ihrem Profil (z.B. Haarfarbe, Augenfarbe) für jede der Eigenschaften hab ich eine Spalte angelegt. Desweiteren speicher ich z.B. Bewertungen (Punkte in einer Spalte und Anzahl Bewertungen in einer anderen, die Bewertung wird dann mit Punkte/Anzahl ermittelt), sowie Newsletteroptionen usw.

Jedenfalls ist es so, dass das alles Punkte sind, die nur mit einer 1:1 Beziehung abgelegt werden.

[Arni]

Mach da eine eigene Tabelle draus.

Ist für die Optimierung sinvoller und lass nur die Userrelevanten Daten
in der User Tabelle

[Friedward74]

Wie unterscheide ich denn, was userrelevant ist und was nicht. Wenn ich ein User-Profil aufrufe werden schließlich immer alle Daten mit angezeigt.

Verstehen kann ich´s ja bei Textfelder (Selbstbeschreibung etc.), die eh nicht durchsucht werden, aber die anderen Kriterien sind ja zum Großteil in der Suche, die schon recht häufig genutzt wird. Das müßte dann ja immer über JOINS verbunden werden. Ist DAS performanter?

[onemorenerd]

Original geschrieben von Friedward74
Wie unterscheide ich denn, was userrelevant ist und was nicht. Wenn ich ein User-Profil aufrufe werden schließlich immer alle Daten mit angezeigt.

Die Newsletteroptionen auch? Kann man bei dir über die Suche wirklich alles über jeden User erfahren? Wohl kaum.

Um bei dem Beispiel zu bleiben: Die Newsletteroptionen brauchst du nur, wenn du Newsletter verschickst oder der User seine Daten ändert. Beides passiert selten bzw. muß nicht hochperformant sein.
Also: Newletteroptionen sind nicht userrelevant.

[xManUx]

Original geschrieben von Friedward74
Wie unterscheide ich denn, was userrelevant ist und was nicht. Wenn ich ein User-Profil aufrufe werden schließlich immer alle Daten mit angezeigt.

Verstehen kann ich´s ja bei Textfelder (Selbstbeschreibung etc.), die eh nicht durchsucht werden, aber die anderen Kriterien sind ja zum Großteil in der Suche, die schon recht häufig genutzt wird. Das müßte dann ja immer über JOINS verbunden werden. Ist DAS performanter?

Ich denke schon, es auch einfacher ein Hotel zu durchsuchen, dass 10 Zimmer hat, als ein Hotel, dass 1000 Zimmer hat.

[Friedward74]

Danke erstmal für die Tips.

Aber nochmal zu den Textfeldern, die ja kaum durchsucht aber dafür bei jedem Profiaufruf angezeigt werden. Sind die "userrelevant" oder eher nicht? Bei mit ID indexierter Zweittabelle sollte ein JOIN hier ja auch recht gute Performance bringen. Nur frag ich mich, ob ich die Abfragen dadurch nicht unnötig aufblähe.