Datenbankaufbau, Tabellenaufbau, Welche Felder benötige ich?

[Spamversender]

SELECT uid, Hobbys.inhalt, Motto.inhalt, Musik.inhalt, ...
FROM
Hobbys, Motto, Musik, Sportarten, ...
WHERE UserID = uid

So müsste das lauten, die fettgedruckten Tabellennamen einfach noch vor die Spalten...wenn du für jede UserID die passenden Inhalte willst

uid musst du dann in PHP in geeignete variablen umwandeln... beim SELECT solltest du es eher nicht brauchen

[akretschmer]

SELECT uid, Hobbys.inhalt, Motto.inhalt, Musik.inhalt, ...
FROM
Hobbys, Motto, Musik, Sportarten, ...
WHERE UserID = uid

So müsste das lauten, die fettgedruckten Tabellennamen einfach noch vor die Spalten...wenn du für jede UserID die passenden Inhalte willst

nein, das ist gruselig, weil keine expliziete JOIN-Syntax und führt sehr, sehr schnell zu ungewollten Schwangerschaften, ähm, Cross-Joins.

[akretschmer]

Was will ich eigentlich abfragen?

Ich habe ~25 Tabellen (Hobbys, Motto, Musik, Sportarten, ...) und möchte aus jeder dieser Tabelle die EINE Zeile mit der UserID raus fischen, aber weiß nicht wie ich die JOIN´s weiter machen soll, wenn es so viele Tabellen sind, hab auch gelesen, dass bei 60 Joins Schluss wäre (aber das sollte für mich nicht relevant sein^^).

Nein, du kannst auch 1 Million Joins machen. Zumindest in richtigen Datenbanken. http://www.cybertec.at/next-stop-joi...illion-tables/

Davon abgesehen solltest Du aber das in eine gescheitere Form bringen. So ist das derzeit Müll.

[Spamversender]

Stimmt, ich hatte noch was vergessen: müsstest im WHERE dann das machen: Hobbys.userID = uid AND Motto.userID = useID usw.

Aber du bist dir im Klaren dass es mit 25 Joins schnell unübersichtlich werden kann?

[akretschmer]

Stimmt, ich hatte noch was vergessen: müsstest im WHERE dann das machen: Hobbys.userID = uid AND Motto.userID = useID usw.

Nein. Kinder, gewöhnt Euch das ab. Join-Conditions haben einen extra Platz.

[fckw]

So ist das derzeit Müll.

könntest du bitte ausführen was Müll ist?
Wo ich wohl wieder bei der Normalisierung gelandet wäre.

...sehr schnell zu ungewollten Schwangerschaften...

na das wollen wir doch nicht

Die gruselige Art ist aber leider für mich momentan die "verständlichere"*g*
Ist für mich momentan die "logischere" Struktur, da einfacher und übersichtlicher vom Aufbau!

Werde mir das mit Join aber noch mal besser ansehen, vielleicht ist es dir möglich eine Minimalversion der Abfrage, bezogen auf meine Tabllen, mit Join zu posten?


Danke!
Schönen Sonntag noch!

Lg
Fckw

[akretschmer]

könntest du bitte ausführen was Müll ist?
Wo ich wohl wieder bei der Normalisierung gelandet wäre.

Wenn weitere Eigenschaften dazukommen, kommen bei Deinem Modell weitere Tabellen dazu. Das skaliert nicht. Du könntest auf EAV ausweichen, was aber teilweise auch gruselig ist. Ich an Deiner Stelle würde hier mal JSON wählen, in PostgreSQL mit Datentyp JSONB (das B steht für binary).

http://www.postgresql.org/docs/9.4/s...type-json.html
http://michael.otacoo.com/postgresql...ndexing-jsonb/
http://www.depesz.com/2014/03/25/wai...-storing-json/

Oder HSTORE. Ist ein Key-Value-Dingens.

[fckw]

und wenn ich das ganze wieder zusammenfasse / denormalisiere?

1. Tabelle mit ALLEN Userdaten. Auch jeden Feldinhalt den der User angegeben hat.
2. Tabelle enthält alle zu überprüfenden Einträge
3. Tabelle für die Ratings der Einträge

Sobald ein Eintrag angenommen wurde wird er in die UserTabelle übernommen und die Einträge in Tabelle 2 & 3 können gelöscht werden.

Glaube fast ich mute mir und euch hier zu viel zu!

Lg

[Montero]

Daten aus beiden Tabellen nur einmal und nie wieder auftauchen.




ipad air 2 hülle