[DB-Design]: Booleans als Bitfeld oder int?

[yankee]

ich haette mal eine theoretische Frage zum Thema DB-Design.
Und zwar habe ich eine DB, die eine Reihe boolesche Werte abspeichert.
Also ich mach mal ein Beispiel: Eine Rechtetabelle waere Recht typisch. Es gibt haufenweise Rechte, die jeder Benutzer hat oder nicht hat. Also alles Booleans.

Eigentlich wuerde ich sagen, dass man sich einfach fuer jedes Recht dann eine Konstante definiert und so dann auf die einzelnen bits eines ints zugreift. So kann man in einem tinyint schonmal 8 Rechte speichern.
Allerdings habe ich festgestellt, dass andere progs (beispielsweise phpbb oder teamspeak) in ihren Datanbanken einfach fuer jedes Recht eine eigene Spalte mit dem Datentyp tinyint anlegen, der nur 0 oder 1 ist.
Warum sollte man das machen? Bitfelder wuerden doch weniger Platz wegnehmen... Und solange man nicht gerade mit einem Programm wie phpmyadmin oder so direkt in der DB rumwurschtelt ist da doch auch kein Nachteil drin, oder?

[Bernhard Geyer]

Nicht jede Datenbank hat Bitfelder und alles was über (n)varchar und integer hinausgeht mußt Du eh für jede Datenbank u.U. speziell behandeln. Selbst "Memo"-Felder verhalten sich unterschiedlich.

[Sharky]

Hai yankee,

Zitat:

Zitat von yankee

... Warum sollte man das machen? Bitfelder wuerden doch weniger Platz wegnehmen...

Ich würde in diesem Fall auch für jedes "Recht" ein eigenes Feld (natürlich in einer eigenen Tabelle) anlegen.
Das ganze ist einfach leichter zu warten. Wenn Du die Rechte in einem Integer speicherst (Bit-Masken) musst Du dir erst wieder eine Doku ausdrucken in der steht welches Bit für was da ist. Und wenn mal ein anderer mit deiner DB arbeiten soll muss auch er sich das erst verinnerlichen.

Ich störe mich da nicht an den wenigen Byte mehr. Wie viele Rechte hat man denn? 10? 100? 1000?
Selbst wenn es 1000 sind (uff, kann ja keiner überschauen) dann sind das gerade mal 1k pro Datensatz. Jetzt verkünpfst Du die Rechte ja nicht direkt mit einem User sondern legst noch eine Tabelle mit "Gruppen" an. Ein User ist also Mitglied einer Gruppe und bezieht darüber die Rechte die er hat. Es werden also auch nur ca. 10 Gruppen sein. Das sind dann gerade mal 10kByte für die Rechtetabelle.

Nicht viel finde ich. Und lieber "verliere" ich einige kByte auf dem DB-Server habe aber dafür ein System was ich noch pflegen kann.

[yankee]

Zitat:

Zitat von Bernhard Geyer

Nicht jede Datenbank hat Bitfelder und alles was über (n)varchar und integer hinausgeht mußt Du eh für jede Datenbank u.U. speziell behandeln. Selbst "Memo"-Felder verhalten sich unterschiedlich.

ich rede ja von integers. Man kann ja mit bitweisen Operatoren auf jedes Bit eines integers zugreifen. Der Integer, der 32 bit hat kann so 32 boolesche Werte aufnehmen.
Also
1 = 1
10 = 2
11 = 3
100 = 4
101 = 5
111 = 6
(Ich hoffe das stimmt so mit der Binaerdarstellung ist fuer die theorie jetzt aber eh egal)
Also wenn ich in einem integer eine 6 speichere wuerde dass dann (sagen wir mal wir haben 3 rechte zu vergeben) true true true heissen und eine 5 wuerde true false true heissen usw.

keine unterstuetzung der DB benoetigt.

[fkerber]

Hi!

Allerdings ist doch dann die Frage, was performanter ist, oder?
Es müsste doch dann (um beim Beispiel eines Forums zu bleiben) dieser Integer immer zerflückt werden, um zu schauen, ob der jeweilige User die entsprechenden Rechte hat.

Anderen Falls geh ich einfach hin und frag das eine Feld ab, dass ich gerade brauche und da steht dann 0 oder 1 drin. Dann muss ich (mal auf PHP bezogen) nicht an den Werten herumarbeiten. Auch wenn ich einen Wert neu setzen will, dann muss ich mich nich um die anderen kümmern usw. usf.


Ciao Frederic

[Der_Unwissende]

Hi,
einerseits ist deine sechs hier falsch (110 = 6, 111 = 7), andererseits

Zitat:

Zitat von yankee

Also wenn ich in einem integer eine 6 speichere wuerde dass dann (sagen wir mal wir haben 3 rechte zu vergeben) true true true heissen und eine 5 wuerde true false true heissen usw.

Zitat:

Zitat von Sharky

Wenn Du die Rechte in einem Integer speicherst (Bit-Masken) musst Du dir erst wieder eine Doku ausdrucken in der steht welches Bit für was da ist. Und wenn mal ein anderer mit deiner DB arbeiten soll muss auch er sich das erst verinnerlichen.

Oder anders gesagt 6 = True True False heißt was? Ok, hab zwei Rechte aber welche?! Gut, kann ich in der Doku nachlesen und dann stelle ich fest dass ich ein Recht nicht mehr brauche und passe dass Bit dann in jedem Integer an? Oder ich brauche mal ein 32tes Recht, dann mach ich was?

Es lohnt sich einfach nicht hier Platz sparen zu wollen. Wie Sharky schon sagte du gibst die Wartbarkeit auf (was so ungefähr zu der Top 3 der Fehler gehört) und das ohne Not. Sagen wir mal du würdest 10 MByte an Rechten speichern, dann schau dir mal an wie viel das an Speicher ist (gar nichts!) und dann noch Sharky's Rechnung dass du für 100te Rechte gerade mal KByte brauchst. Wo also ist hier die Not Platz zu sparen?
Wenn du nun an irgendeiner Stelle noch einen Fehler mit der Bitmaske (oder derer Kombination) machst, dann kommen noch vermeidbare Fehler hinzu. Auch wenn es dir gerade alles klar ist und du diese Fehler ausschließen könntest, so sieht es in einem halben Jahr auch für dich anders aus (und erst recht für andere Entwickler).

Gruß Der Unwissende

[yankee]

uff.... gut, ich werde wohl extra-felder nehmen...

[bigg]

moin,

du verletzt mit deinem Vorhaben eine grundlegenende Regel des Datenbankdesigns, die 1. Normalform!
http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)#Erste_Normalform_.281NF .29

[yankee]

Zitat:

Zitat von bigg

du verletzt mit deinem Vorhaben eine grundlegenende Regel des Datenbankdesigns, die 1. Normalform!
http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)#Erste_Normalform_.281NF .29

Eigentlich kenne ich Normalformen ja
*den Artikel bei wikipedia trotzdem ochmal schnell ueberflieg*
Und ja, Normalformen habe doch eigentlich nur was mit Redundanzen zu tun. Zumindest bis zur 3. Normalform und darueber hinaus ist das ganze eh nur fuer besonder Faelle interssant (sag ich mal so).
Aber egal, du sagst ja schon ich mache bei der 1. Normalform was falsch. Was denn?

[negaH]

Du kannst per SQL keine Relationen über deine Bitfelder mehr erzeugen, so einfach. Auch wenn es deine SQL Datenbank kann, es ist kein Standard und nicht jede SQL kann sowas abarbeiten, bzw. jede Datenbank macht das auf ihre Weise.

Gruß Hagen