nicht angemeldet
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