dreamcatcher

Eigenbemühungen:
Google bringt mich bei dieser Frage leider nicht weiter.
Ich habe bereits "ab wann zwei tabellen users", "mehrere tabellen users", "sinnvoll zwei tabellen" bei google eingegeben.

Ich bekomme meistens Fragen wie ein JOIN Statement funktioniert o.Ä..

Vorspiel:
Vorher hatte ich solche Daten in meiner Users Tabelle:

Jetzt ist die Datenmenge jedoch angewachsen auf:

Die Frage ist, ob es sinnvoll ist oder "best practise" Daten in eine extra Tabelle auszulagern.

Ich hatte z.B. an eine users_details Tabelle gedacht.
In users würde dann nur noch folgendes stehen:

Variante 1.)

Der Rest würde entsprechend in die users_details kommen.

Variante 2.)

Der Rest würde entsprechend in die users_details kommen.
First & Last Name würde ich in der normalen Users belassen, um schnell an einen bestimmten Account zu kommen anhand des Namens.

Variante 3.)
Der Rest würde entsprechend in die users_details kommen.
Der Sinn hinter dieser Aufteilung ist, dass das die Standarddaten sind welche bei der Registrierung aufgenommen werden.
Alle Dateien die später intern hinterlegt werden sind dann quasi die "details".

Variante 4.)
Alle Daten in eine Tabelle packen.

Meine Frage:
Macht man so etwas überhaupt, nur um eine Tabelle nicht voll zu hauen ?
(Als Referenz kenne ich eine Programmiererin die alles in einer Tabelle hat und nichts extra splittet)

Sollte die Frage mit ja beantwortet werden:
Macht die vorgeschlagene Aufteilung von mir Sinn oder gibt es eine sinnvollere ?
Welche Variante würdet ihr wählen ?

P.S.:
dob = date of birth

P.P.S.:
- Ich hätte es in das Software-Design Unterforum gestellt, wenn dort nicht stehen würde "auf PHP Ebene" -
Daher habe ich mich für die DB Sektion entschieden.

Mister Ad

ChrisB

Wenn du das auftrennen willst, dann würde ich die Unterteilung vornehmen in Werte, die für den Betrieb deines Systems absolut notwendig sind (Username, Passwort, Email, ...), und anderen Werten, die vielleicht “nice to have” sind, aber nicht wirklich essentiell (bspw. der persönliche Kram, den ein Nutzer in seinem Profil über sich preisgeben möchte). Das könnten schon mal problemlos zwei Tabellen account und profile sein.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

JuKu

Ich würde es auch so machen.
Die Daten, die du z.B. zum anmelden brauchst, in die eine Tabelle und das Profil-Zeugs, ... in die andere Tabelle.
Muss man sich vorher überlegen, was man oft braucht, in die 1. Tabelle.
Bei Anmeldung, Brauchst du dann kein LEFT JOIN, ...

nikosch

Also mit Verlaub.. Du glaubst doch nicht, dass man mit solchen Begriffen solche Fragen recherchiert bekommt! Schon davon ab, dass die Frage sehr subjektiv ist - je nach Aspekten wie Performance, wirst DU das Problem schon näher eingrenzen müssen.

Das Konzept Normalisierung ist Dir doch bekannt oder?

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

achtelpetit

Über welche Datenmengen reden wir denn hier?
Mach doch einfach mal den Versuch, die ungeteilte Tabelle und alternativ die "Rumpftabelle" abzufragen. Wenn da Zeitunterschiede auftreten (ich meine solche, die in der Praxis eine Rolle spielen) hast Du deine Indizes nicht gut gesetzt, Deine Abfrage sehr unklug aufgebaut oder tatsächlich Datenmengen, auf die Google neidisch wäre.
Kurz und gut: es gibt nur ganz selten einen Grund, eine 1:1-Beziehung zwischen Tabellen aufzubauen. Außer dem Fall der Riesendatenmengen (Bilder oder andere BLOBs) fällt mir noch die Rechteverwaltung ein, und selbst da würde ich zuerst mal über eine Aufteilung mit Views nachdenken.

dreamcatcher

@nikosch
Ich wusste nicht wonach man suchen soll, daher fing ich "umgangssprachlich" an.

Der Begriff der Normalisierung war mir noch nicht bekannt.
Das ist etwas, was ich unterbewusst anwende, aber noch nicht als Thema fassen konnte.

Wikipedia hat sehr geholfen.
Ich lasse alles in einer Table, erspart mir einige unnötigen Joins.