Umsetzungsproblem von Datenaufteilung

Hallo!

Ich habe hier ein Problem bei der logischen Umsetzung meines Vorhabens. :-(

Also, ich muss es irgendwie Umsetzen, Daten eines Protokolls in Mysql
abzuspeichern. Die Basisdaten, eines solchen Protokolls bestehen immer aus
12 verschiedenen Elementen.

Jetzt sind das aber nicht alle Daten. Derjenige, der das Protokoll
ausfüllt, kann über zahlreiche Checkboxen, die in verschiedenen Gruppen
aufgeteilt sind, Optionen für das Protokoll (de)aktivieren.

zb:
--Gruppe 1------------------- --Gruppe 2-----
| [o] OptionX [o] OptionY | | [o] OptionZ |
----------------------------- ---------------

Die Menge dieser Optionen und Gruppen kann in jeden Protokoll anders sein
aber die
Gesammtmenge der Optionen liegt immer im Bereich zwischen 24 und 33.

Kompliziert wa? ;-)

Jetzt hab ich mir gedacht, das ich für jede Option ein
ENUM('ON','OFF','HIDDEN') Feld
nehme, aber damit besteht ein Datensatz dann aus 45 Feldern. Das ist, nach
meinem Empfinden viel zu viel!

Da muss es doch einen Weg geben, um das vernünftig umzusetzen. Bitte um
Hilfe.
Ich hoffe meine Infos reichen aus um mein Problem verstehen zu können.

Mysql-Version ist 3.23 (noch was altes ;~))

Pit

Re: Umsetzungsproblem von Datenaufteilung

On Tue, 31 Jan 2006 16:51:05 +0100, Pit Meyer wrote:

> Hallo!
>
> Ich habe hier ein Problem bei der logischen Umsetzung meines Vorhabens.
> :-(

PS.:

Da ich das gerade lerne bitte ich um Nachsicht falls ich mich nicht
korrekt genug ausgedrückt haben sollte, aber im Normalfall frag ich meinen
Chef.
Da der aber gerad im Theater sitzt muss ich halt hier fragen. :(

Pit

Re: Umsetzungsproblem von Datenaufteilung

Hi Pit!


> Jetzt sind das aber nicht alle Daten. Derjenige, der das Protokoll
> ausfüllt, kann über zahlreiche Checkboxen, die in verschiedenen Gruppen
> aufgeteilt sind, Optionen für das Protokoll (de)aktivieren.
>
> zb:
> --Gruppe 1------------------- --Gruppe 2-----
> | [o] OptionX [o] OptionY | | [o] OptionZ |
> ----------------------------- ---------------
>
> Die Menge dieser Optionen und Gruppen kann in jeden Protokoll anders sein
> aber die
> Gesammtmenge der Optionen liegt immer im Bereich zwischen 24 und 33.
>
> Kompliziert wa? ;-)
>
> Jetzt hab ich mir gedacht, das ich für jede Option ein
> ENUM('ON','OFF','HIDDEN') Feld
> nehme, aber damit besteht ein Datensatz dann aus 45 Feldern. Das ist, nach
> meinem Empfinden viel zu viel!

Kommt vom Blickpunkt an. In PHPMyAdmin gibt das schon eine ziemlich
lange Liste (-;

Vielleicht hilft es, die Spaltennamen automatisiert zu bilden. Dazu
musst Du die Spaltennamen nach einem einheitlichen Schema bilden, z.b.
option_a1, option_a2, option_b1 etc.
Dabei musst Du aber aufpassen, das auch wirklich nur auf existierende
Spaltennamen zugegriffen wird. Stichwort Whitelist.

Die Alternative mit ganz wenig Spalten wäre, alle Optionen in einem
Feld zu speichern.

a1:ON;a2:HIDDEN;...


Bye

--

Re: Umsetzungsproblem von Datenaufteilung

Am Tue, 31 Jan 2006 23:51:14 +0100 schrieb Bodo Kaelberer:

> Die Alternative mit ganz wenig Spalten wäre, alle Optionen in einem
> Feld zu speichern.

Das wäre nun wirklich überhaupt keine Alternative, weil es jedem
vernünftigem DB-Design widerspricht.

Eine echte Alternative wäre, die Optionen in einer eigenen Tabelle zu
speichern: OPTIONS_SET (BASIS_ID, OPTION_ID) enthält die gesetzten Optionen
für einen Basisdatensatz. Die Tabelle ließe sich auch problemlos um z.B.
STATUS erweitern, wenn es um mehr als 2 Stati geht. Die komplette Liste der
verfügbaren Optionen wird in OPTIONS (ID, BESCHREIBUNG) gespeichert.

Gruß
Carsten

Re: Umsetzungsproblem von Datenaufteilung

Hi

Carsten Heinrich am Wed, 1 Feb 2006 07:07:46 +0100:

> > Die Alternative mit ganz wenig Spalten wäre, alle Optionen in einem
> > Feld zu speichern.
>
> Das wäre nun wirklich überhaupt keine Alternative, weil es jedem
> vernünftigem DB-Design widerspricht.

Nicht unbedingt. Die DB schert sich nicht drum, was in einem Feld
sieht und wieviele Daten das aus Sicht des Programmes sind. Man kann
das als Frage des Designs im Programm und nicht in der DB betrachten.


> Eine echte Alternative wäre, die Optionen in einer eigenen Tabelle zu
> speichern: OPTIONS_SET (BASIS_ID, OPTION_ID) enthält die gesetzten Optionen
> für einen Basisdatensatz. Die Tabelle ließe sich auch problemlos um z.B.
> STATUS erweitern, wenn es um mehr als 2 Stati geht. Die komplette Liste der
> verfügbaren Optionen wird in OPTIONS (ID, BESCHREIBUNG) gespeichert.

In der Theorie sehr schön. Wenn man sich das dann aber z.B. mit
PHPMyAdmin anschaut (was beim Entwickeln/Debuggen immer mal passiert),
ist der Zusammenhang zwischen Protokollen und Optionen nicht mehr
erkennbar.
Notwendig wäre es, wenn auch nach Optionen gesucht werden soll (welche
Protokolle haben...).


Bye

--

Re: Umsetzungsproblem von Datenaufteilung

Bodo Kaelberer wrote:

> Vielleicht hilft es, die Spaltennamen automatisiert zu bilden.

Hallo Bodo!

Erst mal danke fuer Deine Hilfe! Warum ich mich jetzt bedanke? :-)
Pit ist mein Azubi.

Dabei hatte ich Ihm alles bereits erklärt. nene so jung und schon Kopf
wie Sieb.

Das wird ganz einfach geloest, in dem alle Flags als serialisiertes
Objekt in die Spalte geschreiben werden. Es besteht keine Notwendigkeit
diese im aktuellen Fall getrennt aufzubewahren.

MfG, Ulf

Re: Umsetzungsproblem von Datenaufteilung

Bodo Kaelberer schrieb:
> Carsten Heinrich am Wed, 1 Feb 2006 07:07:46 +0100:
>
>> > Die Alternative mit ganz wenig Spalten wäre, alle Optionen in einem
>> > Feld zu speichern.
>>
>> Das wäre nun wirklich überhaupt keine Alternative, weil es jedem
>> vernünftigem DB-Design widerspricht.
>
> Nicht unbedingt. Die DB schert sich nicht drum, was in einem Feld
> sieht und wieviele Daten das aus Sicht des Programmes sind. Man kann
> das als Frage des Designs im Programm und nicht in der DB betrachten.

Eine fehlende Normalisierung stellt sich früher oder später immer als
Problem heraus.

>> Eine echte Alternative wäre, die Optionen in einer eigenen Tabelle zu
>> speichern: OPTIONS_SET (BASIS_ID, OPTION_ID) enthält die gesetzten Optionen
>> für einen Basisdatensatz. Die Tabelle ließe sich auch problemlos um z.B.
>> STATUS erweitern, wenn es um mehr als 2 Stati geht. Die komplette Liste der
>> verfügbaren Optionen wird in OPTIONS (ID, BESCHREIBUNG) gespeichert.
>
> In der Theorie sehr schön. Wenn man sich das dann aber z.B. mit
> PHPMyAdmin anschaut (was beim Entwickeln/Debuggen immer mal passiert),
> ist der Zusammenhang zwischen Protokollen und Optionen nicht mehr
> erkennbar.

Das ist ja nun wirklich kein Argument. Wenn ich mir die MySQL-Dateien
auf der Festplatte direkt anschaue, verstehe ich wahrscheinlich auch nur
Bahnhof. Außerdem kann man auch in phpMyAdmin ein LEFT JOIN eingeben.

MfG
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
------------------------------------------------------------ ----

Re: Umsetzungsproblem von Datenaufteilung

Niels Braczek am Wed, 01 Feb 2006 12:57:09 +0100:


> > Nicht unbedingt. Die DB schert sich nicht drum, was in einem Feld
> > sieht und wieviele Daten das aus Sicht des Programmes sind. Man kann
> > das als Frage des Designs im Programm und nicht in der DB betrachten.
>
> Eine fehlende Normalisierung stellt sich früher oder später immer als
> Problem heraus.

Die Normalierung dient dazu die Beziehungen zwischen Datensätzen bzw.
Tabellen zu optimieren.
Wie ich die enthaltenen Inhalte verwalte hat dazu nur einen geringen
Bezug - es muss ich nicht jedes Datum in einer separaten Spalte
wiederfinden.


> > In der Theorie sehr schön. Wenn man sich das dann aber z.B. mit
> > PHPMyAdmin anschaut (was beim Entwickeln/Debuggen immer mal passiert),
> > ist der Zusammenhang zwischen Protokollen und Optionen nicht mehr
> > erkennbar.
>
> Das ist ja nun wirklich kein Argument. Wenn ich mir die MySQL-Dateien
> auf der Festplatte direkt anschaue, verstehe ich wahrscheinlich auch nur
> Bahnhof.

Aus meiner Sicht ein ziemlich schlechter Vergleich (-;

> Außerdem kann man auch in phpMyAdmin ein LEFT JOIN eingeben.

Bloss wer konfiguriert das schon so.

--

Re: Umsetzungsproblem von Datenaufteilung

Hi Pit

Pit Meyer wrote:
> Also, ich muss es irgendwie Umsetzen, Daten eines Protokolls in Mysql
> abzuspeichern. Die Basisdaten, eines solchen Protokolls bestehen immer
> aus 12 verschiedenen Elementen.
> Jetzt sind das aber nicht alle Daten. Derjenige, der das Protokoll
> ausfüllt, kann über zahlreiche Checkboxen, die in verschiedenen Gruppen
> aufgeteilt sind, Optionen für das Protokoll (de)aktivieren.
> Die Menge dieser Optionen und Gruppen kann in jeden Protokoll anders
> sein aber die
> Gesammtmenge der Optionen liegt immer im Bereich zwischen 24 und 33.

Die altbekannte Frage. Einmal mehr:
Du kannst

a) Handorgeln, d.h. transponieren, wie es Carsten erklärte.

b) Codieren, wie es Bodo erklärte. Aber das ist eher weniger gut, wegen
miserablen Indexmöglichkeiten. Und wenn, dann würde ich's im Binärsystem
codieren. Bei max. 33 Optionen gibt das eine Zahl zwischen 0 und 2^33.
Das verkleinert die Datenbasis und verschnellert deshalb die Suche nach
einem gewissen Wert. Dann kannst du da mit AND arbeiten.

c) Dasselbe kannst du aber auch mit SET() lösen. MySQL kann damit noch
etwas besser umgehen als mit b)

d) Jede Option als eigenes Attribut. Das ist ungünstig, weil jede Spalte
mindestens ein Byte Speicher benötigt, obwohl du nur ein Bit benötigen
würdest.

> Jetzt hab ich mir gedacht, das ich für jede Option ein
> ENUM('ON','OFF','HIDDEN') Feld
> nehme, aber damit besteht ein Datensatz dann aus 45 Feldern. Das ist,
> nach meinem Empfinden viel zu viel!

Was heisst schon 'viel'? Nein, 45 Attribute sind noch nicht viel.

> Da muss es doch einen Weg geben, um das vernünftig umzusetzen. Bitte um
> Hilfe.
> Ich hoffe meine Infos reichen aus um mein Problem verstehen zu können.
> Mysql-Version ist 3.23 (noch was altes ;~))

Das ist update-fähig! ;-)
HTH, Johannes