Speichern von meherern boolean-Werten in einer Spalte?

[Christian]

Einen schönen Samstag allerseits!

Ich nutze PHP & MySQL.

Bisher habe ich jede Variable mit nur zwei möglichen Zuständen in eine extra Tinyint-Tabellenspalte abgespeichert, also entweder 1 oder 0 eingesetzt.
Bei diesen Variablen handelt es sich um persönliche Einstellungen eines Benutzers o.Ä.

Jetzt habe ich 5 solche Variablen, die inhaltlich sehr eng zusammen hängen.

Sollte ich für jeden Parameter nun wieder eine neue Tabellenspalte erstellen?

Als Alternative habe mir gedacht, dass ich die Variablen vielleicht kombinieren kann, wie es auch bei chmod gemacht wird.
also beispielsweise:
Param1 true -> $var += 1;
Param2 true -> $var += 2;
Param3 true -> $var += 4;
Param4 true -> $var +=10;
Param5 true -> $var +=20;

Das ergäbe bei der Tabellengestaltung mehr Übersicht.

Der Nachteil ist dann aber die umständlichere Ausgabe.
Zur Auswahl von Datensätzen mit Param1 true müsste ich dann ja eine Abfrage wie "[...] WHERE var = 1 || var = 3 || var = 7 || var = 11 || var = 13 [...]" benutzen.

Oder ich wähle alle Einträge aus und filter dann mit PHP heraus, indem ich erst die var-Zeichenlänge bestimme und dann checke, ob var{letzteszeichen} (z.b. für Parameter2) == 2 bzw 6 ist.
Für Parameter1 könnte man ja auch checken, ob die Zahl ungerade ist. Wie das geht, weiß ich aber auch nicht. Ich hab in der PHP-Dokumentation mal irgendwas mit nem Prozentzeichen und ner 2 oder so gelesen, aber nicht verstanden, warum das jetzt checkt, ob die Zahl gerade oder ungerade ist.

Wie löst man sowas am besten?

Grüße
Christian

[dedlfix]

echo $begrüßung;

Bisher habe ich jede Variable mit nur zwei möglichen Zuständen in eine extra Tinyint-Tabellenspalte abgespeichert, also entweder 1 oder 0 eingesetzt.

Wie löst man sowas am besten?

Eine Möglichkeit wäre mit dem Spaltentyp SET gegeben.

echo "$verabschiedung $name";

[Tom]

Hello,

Bisher habe ich jede Variable mit nur zwei möglichen Zuständen in eine extra Tinyint-Tabellenspalte abgespeichert, also entweder 1 oder 0 eingesetzt.

Wie löst man sowas am besten?

Eine Möglichkeit wäre mit dem Spaltentyp SET gegeben.

Aber nur dann, wenn ausschließlich alphanumerische Werte refenziert werden sollen. Wenn man numerische dazwischen hat, gibt es Stress, denn MySQL hat hier immer noch eine Macke. Wenn der Wert nicht gefunden wird, wird im Index der Werte gesucht. Das kann zu peinlichen Inkonsistenzen führen.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Christian]

Hi Tom nochmal,

Aber nur dann, wenn ausschließlich alphanumerische Werte refenziert werden sollen.

Wenn ausschließlich _was_ mit alphanumerischen Werten gemacht werden soll?

Wenn man numerische dazwischen hat, gibt es Stress, denn MySQL hat hier immer noch eine Macke. Wenn der Wert nicht gefunden wird, wird im Index der Werte gesucht. Das kann zu peinlichen Inkonsistenzen führen.

Warum ist das eine Macke? Wenn ich die MySQL-Dokumentation richtig verstehe, ist das doch Absicht?
<< Angenommen, eine Spalte ist als SET("a","b","c","d") festgelegt [...]  Wenn Sie dieser Spalte einen Wert von 9 zuweisen, ist das binär 1001. Daher werden der erste und der vierte SET-Wert, die Elemente "a" und "d", ausgewählt, und der Ergebniswert ist "a,d". >>
Oder versteh ich was falsch?

Grüße
Christian

[Tom]

Hello,

Oder versteh ich was falsch?

Ja.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Christian]

Hallo Tom,

Ja.

Aha.

Grüße
Christian

[Christian]

Hallo dedlfix,

danke für deinen Hinweis!
Der Spaltentyp scheint mir sehr hilfreich zu sein.

Grüße
Christian

[Cheatah]

Hi,

Jetzt habe ich 5 solche Variablen, die inhaltlich sehr eng zusammen hängen.

Anrede, Titel, Vorname, Namenszusatz und Nachname sind auch fünf Werte, die inhaltlich sehr eng zusammen hängen. Trotzdem lautet die Frage: Welche Werte sind atomar?

Sollte ich für jeden Parameter nun wieder eine neue Tabellenspalte erstellen?

Sind die Parameter atomar, oder ist nur jeweils ihre Kombination interessant?

Param1 true -> $var += 1;
Param2 true -> $var += 2;
Param3 true -> $var += 4;
Param4 true -> $var +=10;
Param5 true -> $var +=20;

Die letzten beiden Werte verstehe ich nicht.

Das ergäbe bei der Tabellengestaltung mehr Übersicht.

Das ist uninteressant. Welche Werte sind atomar?

Oder ich wähle alle Einträge aus und filter dann mit PHP heraus,

Du willst das Datenbank-Schema von einer Technik abhängig machen, mit der Du im Moment zufällig darauf zugreifst? Also, mein Führerschein bezieht sich nicht auf den Citroen BX, obwohl das genau der Wagen ist, mit dem ich damals gefahren bin.

Wie löst man sowas am besten?

Man normalisiert die atomaren Datenmengen.

Cheatah

[Tom]

Hello,

Also, mein Führerschein bezieht sich nicht auf den Citroen BX, obwohl das genau der Wagen ist, mit dem ich damals gefahren bin.

Jetzt verstehe ich auch Dein gelegentliches Verhalten gegenüber anderen Postern etwas besser ;-))

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Cheatah]

Hi,

Jetzt verstehe ich auch Dein gelegentliches Verhalten gegenüber anderen Postern etwas besser ;-))

warum, weil ich Mamas Auto fahren durfte? ;-)

Cheatah

[Christian]

Hi,

Jetzt verstehe ich auch Dein gelegentliches Verhalten gegenüber anderen Postern etwas besser ;-))

warum, weil ich Mamas Auto fahren durfte? ;-)

Nein, weil du von einer BX-Fahrerin entstammst! ;)

Grüße
Christian

[Fabian Transchel]

Hallo Christian,

warum, weil ich Mamas Auto fahren durfte? ;-)

Nein, weil du von einer BX-Fahrerin entstammst! ;)

Diese These finde ich gewagt, denn selbst ein BX hat wohl doch Probleme 18 Jahre und 9 Monate lang in einem Stück zu bleiben - zumindest so, dass man dann noch damit _fahren lernen_ konnte. Insofern ist es zwar sichergestellt, dass Chetah seiner Mutter entstammt, aber es ist keinesfalls sicher, dass sie schon BX-Fahrerin war, als die "anatomische Entstammung" abgeschlossen war. ;-)

Grüße aus Barsinghausen,
Fabian

[Christian]

Hallo Fabian

Insofern ist es zwar sichergestellt, dass Chetah seiner Mutter entstammt, aber es ist keinesfalls sicher, dass sie schon BX-Fahrerin war, als die "anatomische Entstammung" abgeschlossen war. ;-)

Wer sagt denn, das meine These nur greift, wenn Sie schon BX-Fahrerin war?
Alleine der Fakt, dass sie zu einem späteren Zeitpunkt mal eine BX-Fahrerin werden könnte, reicht doch schon aus!

Grüße
Christian

[Christian]

Hi Cheatah,

Sind die Parameter atomar, oder ist nur jeweils ihre Kombination interessant?

Im Grunde sind sie atomar. Manchmal ist aber auch ihre Kombination von Relevanz. Was ich meine: Eigenschaft a und b sind irrelevant, wenn c nicht gegeben ist.

Param1 true -> $var += 1;
Param2 true -> $var += 2;
Param3 true -> $var += 4;
Param4 true -> $var +=10;
Param5 true -> $var +=20;

Die letzten beiden Werte verstehe ich nicht.

Mit was sollte ich sonst $var addieren? Ich dachte wie gesagt an einen Aufbau ganz wie bei chmod.

Du willst das Datenbank-Schema von einer Technik abhängig machen, mit der Du im Moment zufällig darauf zugreifst? Also, mein Führerschein bezieht sich nicht auf den Citroen BX, obwohl das genau der Wagen ist, mit dem ich damals gefahren bin.

Du hattest ja auch nicht die Absicht, den Führerschein ausschließlich mit deinem BX nutzen zu wollen, oder?

Man normalisiert die atomaren Datenmengen.

Ok.

Grüße
Christian

[Tom]

Hello,

Jetzt habe ich 5 solche Variablen, die inhaltlich sehr eng zusammen hängen.

Sollte ich für jeden Parameter nun wieder eine neue Tabellenspalte erstellen?

Du solltest eine eigene Tabelle T_USER_PROP dafür anlegen.
Dann kannst Du einem Bentuzer auch 20 Eigenschaften zuordnen, obwol ein anderer 50 benötigt und ein dritter gar keine.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Cheatah]

Hi,

Du solltest eine eigene Tabelle T_USER_PROP dafür anlegen.

warum ausgerechnet dieser Name?

Cheatah

[Tom]

Hello,

Du solltest eine eigene Tabelle T_USER_PROP dafür anlegen.

warum ausgerechnet dieser Name?

Weil er als Synonym steht und zum Denken anregen soll.
Aber wer schon in jungen Jahren Citoën BX fahren muss, mit dem habe ich Nachsicht *grins*

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Cheatah]

Hi,

Du solltest eine eigene Tabelle T_USER_PROP dafür anlegen.
warum ausgerechnet dieser Name?
Weil er als Synonym steht und zum Denken anregen soll.

mich regt er vor allem zu dem Denken an, wieso man einen mit "T_" beginnenden Tabellennamen wählen sollte.

Aber wer schon in jungen Jahren Citoën BX fahren muss, mit dem habe ich Nachsicht *grins*

Solange Du nicht auf Nachtschicht mit mir bestehst ... ;-)

Cheatah

[Christian]

Hallo Tom,

du meinst also, ich soll für jede Eigenschaft eine eigene Tabelle mit einem Feld anlegen, wo dann die Objekte eingetragen werden, denen diese Eigenschaft zugeordnet werden soll?

Grüße
Christian

[Tom]

Hello,

du meinst also, ich soll für jede Eigenschaft eine eigene Tabelle mit einem Feld anlegen, wo dann die Objekte eingetragen werden, denen diese Eigenschaft zugeordnet werden soll?

Das hängt nun wieder vom Datentyp der Eigenschaften ab.
Wenn alle EIgenschaften denselben Datentyp haben, kannst Du sie in einer tabelle zusammenfassen und klassifizieren. Wenn nicht, muss eine n:m Verknüfung zwischengeschaltet werden.

Das ist eines der klassischen Probleme der Normalisierung: Typen-Berücksichtigung!

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Christian]

Hi Tom,

Das hängt nun wieder vom Datentyp der Eigenschaften ab.

Nach meinem Verständnis von Eigenschaften kann einem Element (Benutzer, Mitteilung) diese zugeordnet werden oder nicht.
Warum redest du von Datentypen?

Wenn alle EIgenschaften denselben Datentyp haben, kannst Du sie in einer tabelle zusammenfassen und klassifizieren.

Verstehe ich nicht. Wozu eine neue Tabelle, wenn sie doch wieder mehrere Felder hat?
Unter einer Klassifizierung kann ich mir nichts vorstellen.

Das ist eines der klassischen Probleme der Normalisierung: Typen-Berücksichtigung!

Diese Aussage bringt mir so nichts.

Grüße
Christian

[Tom]

Hello,

Das hängt nun wieder vom Datentyp der Eigenschaften ab.
Nach meinem Verständnis von Eigenschaften kann einem Element (Benutzer, Mitteilung) diese zugeordnet werden oder nicht.
Warum redest du von Datentypen?

Welche Eigenschaften könnte denn ein Objekt haben?

- Größe in Metern (numerisch)
 - Hautfarbe in Worten
 - Bescheibung in ganzen Sätzen
 - Lebend/Tot als logischem Wert
 - Kontonummer als Zahl
 - IP als Sonderstring

usw.

alles Eigenschaften des Objektes. Es könnte beliebig viele geben. Sie werden nicht alle denselben Datentyp haben. Willst Du nun für jede Eigenschaftsart eine eigene Tabelle aufmachen? Wie würdest Du die Eigenschaften mit dem Objekt verknüpfen?

Diese Aussage bringt mir so nichts.

Wie hättest Du sie denn gerne?

Christian

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Christian]

Hi Tom,

alles Eigenschaften des Objektes. Es könnte beliebig viele geben. Sie werden nicht alle denselben Datentyp habe.

Habe ich mich unverständlich ausgedrückt mit dem Typ meiner Eigenschaften? Ich dachte, dass wäre schon mit der Überschrift "boolean-Werte" klar.

Diese Aussage bringt mir so nichts.
Wie hättest Du sie denn gerne?

Sie bringt mir nichts, weil ich kein Zusammenhang zu meinem Problem herstellen kann.

Willst Du nun für jede Eigenschaftsart eine eigene Tabelle aufmachen?

Ich denke, ich gehe dedlfixs (oder besser dedlfixens?) Tipp mit dem Spaltentyp SET nach.

Wie würdest Du die Eigenschaften mit dem Objekt verknüpfen?

Ich würde einfach nur die Objekte in die Eigenschaftstabelle schreiben.
Aber das interessiert mich: Kann man Verknüpfungen anstatt Werte setzen?
Bsp: ein Wert der Spalte 'autor' in der Tabelle 'nachrichten' soll immer den aktuellen Wert der Spalte 'name' und der Zeile mit der 'id' = 27 in der Tabelle 'autoren' haben.

Grüße
Christian

[Vinzenz Mai]

Hallo Christian,

Aber das interessiert mich: Kann man Verknüpfungen anstatt Werte setzen?
Bsp: ein Wert der Spalte 'autor' in der Tabelle 'nachrichten' soll immer den aktuellen Wert der Spalte 'name' und der Zeile mit der 'id' = 27 in der Tabelle 'autoren' haben.

Dein Datenbankdesign lässt hier zu wünschen übrig:

In Tabelle 'nachrichten' sollte sich eine Spalte 'autor_id' oder so ähnlich befinden, die dem Wert der Spalte 'id' in der Tabelle 'autoren' entspricht. Ich gehe davon aus, dass die Spalte 'id' der Tabelle 'autoren' Träger des Primärschlüssels ist. Somit wäre die Spalte 'autor_id' in der Tabelle 'nachrichten' Fremdschlüssel. Auf die weiteren Eigenschaften des Autors greifst Du über einen Join über die entsprechenden Spalten zu. Der Name des Autors sollte in der Tabelle 'nachrichten' überhaupt nicht auftauchen.

Freundliche Grüße

Vinzenz

[Tom]

Hello,

alles Eigenschaften des Objektes. Es könnte beliebig viele geben. Sie werden nicht alle denselben Datentyp habe.

Habe ich mich unverständlich ausgedrückt mit dem Typ meiner Eigenschaften? Ich dachte, dass wäre schon mit der Überschrift "boolean-Werte" klar.

*pssst* bitte nicht beißen

Aber zurück zum Thema: Wenn die Datentypen gleich sind, ist das Problem der Modellierung schon wesentlich kleiner:

T_User                T_Property                 T_Property_Class
  id_user ------+       id_property          +---- id_property_class
  -------       |       -----------          |     -----------------
  firstname     +------ id_user              |     property_class
  lastname              id_property_class ---+     remark
  axiliary              property

Wird es jetzt klarer, wie _ein_ Lösungsweg aussehen kann?
Wenn nun aber der Datentyp/Spaltentyp von property von property_class zu property_class nicht identisch ist, wird es eben kompliziert.

Diese Aussage bringt mir so nichts.
Wie hättest Du sie denn gerne?
Sie bringt mir nichts, weil ich kein Zusammenhang zu meinem Problem herstellen kann.

Das sit aber Dein Problem. Wenn man Dir jeden Wurm einzeln aus der Nase ziehen muss, weiß man leider nicht, wo Du nicht mitkommst. Und mitarbeiten solltest Du auch!

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Ilja]

yo,

Jetzt habe ich 5 solche Variablen, die inhaltlich sehr eng zusammen hängen.

wie Cheatah schon gesagt hat, spielen inhalte bei der normalisierung keine rolle. es geht vereinfacht ausgedrückt um atomarität (was genau der begriff bedeutet wird sehr häufig missverstanden) und zum anderen um abhängigkeiten der daten. dies sind aber nur vorschläge und keine muss bedingungen. am ende musst du selbst entscheiden, welche die beste lösung für dich ist.

Sollte ich für jeden Parameter nun wieder eine neue Tabellenspalte erstellen?

das wäre meine empfehlung. sicherlich kann man in einem byte mehrere schalter unterbringen. und es wäre auch nicht "verboten" genau das zu tun. aber ich finde es weniger geeigent zu handhaben, weil man zusätzlich immer die codierung mit betrachten muss.

Param1 true -> $var += 1;
Param2 true -> $var += 2;
Param3 true -> $var += 4;
Param4 true -> $var +=10;
Param5 true -> $var +=20;

auch hier wie bei Cheatah meine frage, warum nach 4 nicht 8 und dann 16 kommt, schließlich handelt es sich doch um eine bit codierung ?

Das ergäbe bei der Tabellengestaltung mehr Übersicht.

nein, dass würde ich nicht sagen, für mich wäre es genau das gegenteil. sicherlich verkürtzt sich die anzahl der spalten der tabelle. aber bleiben wir mal bei dem beispiel der entität einer person. auch dort gäbe es binäre schalter wie zum beispiel mann oder frau, führerschein ja/nein, etc. wenn ich mir nur die rohdaten der tabelle anschauen würde, dann müsste ich auch hier "mühsam" über die codierung verausfiltern, welche bedeutung der inhalt nun hat. sprich ist das erste bit für den führerschein, das geschlecht, etc. würde ich für jede eigenschaft eine eigene spalte haben, könnte ich es viel leichter auf einen blick auswerten.

Der Nachteil ist dann aber die umständlichere Ausgabe.
Zur Auswahl von Datensätzen mit Param1 true müsste ich dann ja eine Abfrage wie "[...] WHERE var = 1 || var = 3 || var = 7 || var = 11 || var = 13 [...]" benutzen.

das ist richtig und wäre ein zusätzlicher aufwand. wenn man eine datenbank erstellt, dann sind mehre punkte zu beachten. sicherlich muss die datenintegrität gesichert werden. aber auch wartbarkeit und performance spielen eine rolle. und die wartbarkeit ist ein nicht zu unterschätzender aspekt. was nützt mir ein system, dass zwar richtig aber so komplex ist, dass ich es nur unter schwierigkeiten verwenden kann.

im prinzip ist beides möglich und es gibt für beides gute argumente. wichtig ist, dass du das für dich beste herausfindest. und sollten noch andere jemals diese datenbank benutzen, dann soltest du auch darüber nachdenken, dass es für sie leicht verständlich ist.

Oder ich wähle alle Einträge aus und filter dann mit PHP heraus, indem ich erst die var-Zeichenlänge bestimme und dann checke, ob var{letzteszeichen} (z.b. für Parameter2) == 2 bzw 6 ist.

das ist nun mit sicherheit kein guter weg, der auf jeden fall vermieden werden sollte. es bringt zuviele nachteile mit sich, nicht nur was die performance betrifft.

Für Parameter1 könnte man ja auch checken, ob die Zahl ungerade ist. Wie das geht, weiß ich aber auch nicht.

wie du selbst schon erwähnt hast, prüft man so etwas in aller regel über den rest einer teilung durch 2. bleibt nichts hinter dem komma, dann ist die zahl gerade, ansonsten ungerade.

noch einmal der hinweis, es gibt kein generelles richtig oder falsch für dein daten-design. du bist in der position, wo du für eine spezielle situation unter berücksichtung mehrerer aspekte die beste lösung herausfinden musst. und das ist fast immer ein kompromiss von vielen argumenten.

Ilja