Bit-Operatoren vs. Normalisierung

Hallo,

Ein zu speichernder Datensatz für ein Produkt enthält folgende=20
Informationen:
- Artnr
- Produktname
- Zustand Etikett

Zustand Etikett kann dabei 0-n von n vordefinierten Werten annehmen=20
(z.B. schmutzig, verblasst, wellig) .

Normalisiert würde ich das in einer Datenbankstruktur wie folgt speiche=
rn:

CREATE TABLE produkte (
artnr int(3) unsigned NOT NULL,
produktname varchar(200) NOT NULL,
PRIMARY KEY (artnr)
) ENGINE=3DInnoDB;

CREATE TABLE produkte_etikett_eigenschaften (
artnr int(3) unsigned NOT NULL,
eigenschaft_id int(1) unsigned NOT NULL,
KEY artnr (artnr),
KEY eigenschaft_id (eigenschaft_id),
FOREIGN KEY (artnr) REFERENCES produkte (art)
ON DELETE UPDATE ON UPDATE CASCADE,
FOREIGN KEY (eigenschaft_id) REFERENCES etikett_eigenschaften
(eigenschaften) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=3DInnoDB;

CREATE TABLE etikett_eigenschaften (
eigenschaft_id int(1) unsigned NOT NULL,
eigenschaft_name varchar(200) NOT NULL,
PRIMARY KEY (eigenschaft_id)
) ENGINE=3DInnoDB;

Die Tabelle produkte_etikett_eigenschaften könnte ich mir aber auch=20
sparen, indem ich in Tabelle etikett_eigenschaften für eigenschaft_id=20
nur Potenzen von 2 verwende und der Tabelle produkte ein zusätzliches=20
Feld für die etikett_eigenschaften hinzufüge, in dem ich die Summe vo=
n=20
eigenschaft_id speichere. Mit Bit-Operatoren lassen sich Suchen und=20
Verknüpfungen mit etikett_eigenschaften problemlos erledigen.
Was sind ggf. Nachteile?

Guido

Re: Bit-Operatoren vs. Normalisierung

Guido Schmidt wrote:

> Ein zu speichernder Datensatz für ein Produkt enthält folgende
> Informationen:
> - Artnr
> - Produktname
> - Zustand Etikett
>
> Zustand Etikett kann dabei 0-n von n vordefinierten Werten annehmen
> (z.B. schmutzig, verblasst, wellig) .

Also ein SET (Menge) von Eigenschaften.

> Normalisiert würde ich das in einer Datenbankstruktur wie folgt speiche
> rn:

[snip]

Ja

> Die Tabelle produkte_etikett_eigenschaften könnte ich mir aber auch
> sparen, indem ich in Tabelle etikett_eigenschaften für eigenschaft_id
> nur Potenzen von 2 verwende und der Tabelle produkte ein zusätzliches
> Feld für die etikett_eigenschaften hinzufüge, in dem ich die Summe vo
> n
> eigenschaft_id speichere. Mit Bit-Operatoren lassen sich Suchen und
> Verknüpfungen mit etikett_eigenschaften problemlos erledigen.

Diese Denormalisierung sieht MySQL selber schon vor und stellt dafür
den SET Datentyp bereit. Damit kann man sich die manuelle Bit-Fizzelei
ersparen und bekommt auch schöne Namen für die Bits.

> Was sind ggf. Nachteile?

Die üblichen Verdächtigen für nicht-normalisierte Datenstrukturen:

- es skaliert nicht. MySQL SETs sind auf 64 Elemente beschränkt, die
Ähnlichkeit mit der Länge von BIGINT in Bits ist nicht zufällig ;-)

- bestimmte Suchvorgänge lassen sich nicht mit Indexen beschleunigen.
Beispiel: Bestimme die Anzahl der Artikel mit verknittertem Etikett


XL

Re: Bit-Operatoren vs. Normalisierung

Axel Schwenke schrieb:

> - es skaliert nicht. MySQL SETs sind auf 64 Elemente beschränkt, die
> Ähnlichkeit mit der Länge von BIGINT in Bits ist nicht zufällig=
;-)

Ist in meinem konkreten Fall nicht relevant.

> - bestimmte Suchvorgänge lassen sich nicht mit Indexen beschleunigen.=

> Beispiel: Bestimme die Anzahl der Artikel mit verknittertem Etikett

Das ist der entscheidende Tipp.
Besten Dank für die Ausführungen!

Guido