Datenbankstruktur fürMehrfachauswahl?

Hallo!

Was ist eine Ideale Datenbankstruktur für Multiple Auswahl?

Ich habe also Daten, z.B. User. Diese können bei verschiedenen
Möglichkeiten eine Mehrfachauswahl (z.B. erlernte Berufe) auswählen.

Ich könnte also eine Tabelle die 'halbstatisch' ist, also die Berufe
beinhaltet, die in der Mehrfachauswahl vorgegeben sind.

Tab. 1:
ID Bezeichnung
1 Maurer
2 Tischler
3 Kelner
usw.

Dann habe ich eine Tabelle in der die User eingetragen werden (Tab. 2).
Und dann kann ich ID's zu ID's zuordnen:

Tab. 3:
UserID, BerufID
1 1
1 2
2 3
3 1
3 3

uws.

Nun habe ich einige Mehrfachauswahlen, ... Das ergibt jede Menge Tabellen.

Welche Möglichkeiten gibts hier um Tabellen zu sparen? Ich habe mal
versucht nur eine Tabelle für die Mehrfachauswahl zu verwenden, mit ID und
einen ENUM Feld. Das kann gut Indiziert werden, macht aber große
Probleme, wenn man z.B. einen Beruf entfernen möchte oder einen anderen
hinzufügen, ...

Was ist hier die 'normalisierte' Art und Weise, die Datenbank zu designen?

Danke für eure Ideen.

Martin

Re: Datenbankstruktur fürMehrfachauswahl?

Martin Kaffanke schrieb:
> Hallo!

Hi,

> Was ist eine Ideale Datenbankstruktur für Multiple Auswahl?
> [...]
> Ich könnte also eine Tabelle die 'halbstatisch' ist, also die Berufe
> beinhaltet, die in der Mehrfachauswahl vorgegeben sind.
>
> Dann habe ich eine Tabelle in der die User eingetragen werden (Tab. 2).
> Und dann kann ich ID's zu ID's zuordnen:
>
> Nun habe ich einige Mehrfachauswahlen, ... Das ergibt jede Menge Tabellen.
>
> Welche Möglichkeiten gibts hier um Tabellen zu sparen?

Was meinst du mit "sparen"? Eine leere Tabelle braucht wenig
Speicherplatz. Die einzige Sorge die man bei der Normalisierung haben
muss, ist die Komplexität der JOINs. Und die ist bei deinem Modell
konstant, denn es müssen immer drei Tabellen "gejoint" werden.

> [...]
> Was ist hier die 'normalisierte' Art und Weise, die Datenbank zu designen?

Meiner Meinung nach genau die, die du genannt hast.

Grüße,
--
Philipp Tölke
PGP: 0x96A1FE7A

Re: Datenbankstruktur für Mehrfachauswahl?

Hallo Martin!

Martin Kaffanke schrieb am 31.07.2006 19:58:
> Was ist eine Ideale Datenbankstruktur für Multiple Auswahl?

Ich bevorzuge diese:

> Tab. 3:
> UserID, BerufID
> 1 1
> 1 2
> [...]

> Nun habe ich einige Mehrfachauswahlen, ... Das ergibt jede Menge Tabellen.
> Welche Möglichkeiten gibts hier um Tabellen zu sparen?

Naja, kommt darauf an was du damit machen willst.
Willst du die Zuordnungen nur speichern und wieder anzeigen, oder willst
du die auch auswerten, z.B. "alle User die Maler sind"? Dann s.O. Sonst
kannst du auch die IDs als Kommaliste in einem Textfeld speichern, zum
Anzeigen reicht das.

> Was ist hier die 'normalisierte' Art und Weise, die Datenbank zu designen?

Kann ich nicht sicher sagen (zu lange her :-) ), aber ich vermute mal s.O.!

> Martin

MfG Thomas.

Re: Datenbankstruktur für Mehrfachauswahl?

Borsdorf, Thomas wrote:
>
>> Nun habe ich einige Mehrfachauswahlen, ... Das ergibt jede Menge
>> Tabellen.
>
> > Welche Möglichkeiten gibts hier um Tabellen zu sparen?
>
> Naja, kommt darauf an was du damit machen willst.
> Willst du die Zuordnungen nur speichern und wieder anzeigen, oder willst
> du die auch auswerten, z.B. "alle User die Maler sind"? Dann s.O. Sonst
> kannst du auch die IDs als Kommaliste in einem Textfeld speichern, zum
> Anzeigen reicht das.

*möööp* Falsche Antwort ;)
Damit verletzt du auf Anhieb die 1NF. Und das willst du ganz sicher
nicht, wenn dir die Performance der Anwendung lieb ist.

Eine von mir praktizierte Möglichkeit ist, alle Auswahlmöglichkeiten in
einer Tabelle zu speichern und über einen Key nur die zu selektieren,
die man für die aktuelle Auswahlliste gerade braucht.
Die Zuordnug zum User passiert dann über eine auto_increment Spalte in
der großen Auswahlliste. Spart zwar massig Tabellen (was die DB
wunderbar übersichtlich hält), aber leider keinen einzigen JOIN...


Grüße,
Dominik
--
Norbert Melzer in d.c.d.mysql:
F: Wie verstehe ich diese FAQ am besten?
A: Studieren Sie Datanbank-Design und lesen Sie anschliessend alles nochmal

Re: Datenbankstruktur für Mehrfachauswahl?

Hallo Dominik!

Dominik Echterbruch schrieb am 31.07.2006 21:30:
> *möööp* Falsche Antwort ;)

Damit kann ich leben :-)
Okay, 1NF ist es nicht, wie ich inzwischen nochmal nachgeschlagen habe.
Aber das hatte ich ja geschrieben, es ist zu lange her...

Trotzdem bleibe ich dabei: Auch wenn es nicht 1NF ist, wenn eine reine
Anzeige der Detail-Daten geht reicht die Kommaliste aus. Dann brauche
ich keine JOINs, ich kann direkt die Kommaliste in das SQL-Statement
reingeben, und das müsste eigentlich schneller sein. Klar, kommt
natürlich auch auf die Menge der Rückgabe-Daten an...

> Grüße,
> Dominik

MfG Thomas.

Re: Datenbankstruktur für Mehrfachauswahl?

Borsdorf, Thomas wrote:
>
>> *möööp* Falsche Antwort ;)
>
> Damit kann ich leben :-)

Das ist schön :)

> Trotzdem bleibe ich dabei: Auch wenn es nicht 1NF ist, wenn eine reine
> Anzeige der Detail-Daten geht reicht die Kommaliste aus. Dann brauche
> ich keine JOINs, ich kann direkt die Kommaliste in das SQL-Statement
> reingeben, und das müsste eigentlich schneller sein. Klar, kommt
> natürlich auch auf die Menge der Rückgabe-Daten an...

Viel wichtiger finde ich in dem Zusammenhang zwei Fragen:
1.) Was ist, wenn man mal nach nur einem der Werte suchen will? Eine
Suche in einem String ist erheblich teurer, als ein Select auf einen
Integer.
2.) Was ist, wenn man doch mal auf die Idee kommt, das irgendwie joinen
zu wollen? Dazu fällt mir dann nicht mal mehr ein Ansatz ein. Jedenfalls
keiner, vor dem ich nicht aufgrund von massiven Gänsehautanfällen
fliehen würde :)

Und ganz nebenbei: Wenn du nicht mal die 1NF haben willst, wozu dann
noch eine Datenbank, da tut's dann auch eine CSV Datei. Klar, der Rest
außen rum ist ja evtl. noch in der 3NF. Und auch klar, SQL ist viel
freundlicher, als direkte Dateioperationen. Aber ich würde hier nicht
versuchen, an der falschen Stelle zu sparen. Denormalisieren kann man
immer noch, wenn es tatsächlich Probleme geben sollte (wovon ich bei
diesem Beispiel nicht ausgehe).


Grüße,
Dominik
--
Norbert Melzer in d.c.d.mysql:
F: Wie verstehe ich diese FAQ am besten?
A: Studieren Sie Datanbank-Design und lesen Sie anschliessend alles nochmal