Ist das Hinzufügen einer Bitmaske zu allen Tabellen in einer Datenbank sinnvoll?

Question

Ein Kollege fügt allen unseren Datenbanktabellen eine Bitmaske hinzu. Theoretisch können wir so bestimmte Eigenschaften jeder Zeile im gesamten System verfolgen. Zum Beispiel ...

• Ist die Zeile mit dem System geliefert oder vom Kunden hinzugefügt, sobald sie begonnen haben, mit dem System
• Hat die Zeile aus der Tabelle (soft Löschungen) gelöscht
• Ist die Zeile ein Standardwert innerhalb einer Reihe von Zeilen

Ist das eine gute Idee? Gibt es andere Anwendungen, bei denen dieser Ansatz von Vorteil wäre?

Meine Präferenz ist, dass diese Eigenschaften offensichtlich wichtig sind, und eine dedizierte Spalte für jede Eigenschaft zu haben, ist berechtigt, das, was passiert, den anderen Entwicklern klarer zu machen.

Answer 1

Nicht wirklich, nein.

Sie können nur Bits darin speichern und nur so viele. Also, es scheint mir, als würde es später auf der Anwendungsebene viele Kopfschmerzen verlangen, um zu verfolgen, was jeder einzelne meint und potentiell missbraucht wird, weil "Hey, sie sind überall". Wird jede Bitmaske auf jedem Tisch dieselbe Definition für jedes Bit verwenden? Wird es auf jedem Tisch anders sein? Was passiert, wenn Ihnen die Bits ausgehen? Neue hinzufügen?

Es gibt viele potenzielle Dinge, die Sie damit machen könnte, aber es stellt sich die Frage: „Warum tun es auf diese Weise, anstatt zu identifizieren, was wir diese Bits für jetzt verwenden und sie nur die richtige Spalten machen? " Sie umgehen die Möglichkeit von Schemaänderungen auf diese Weise sowieso nicht wirklich, also scheint es, als ob es versucht, ein Problem zu lösen, das Sie nicht wirklich "lösen" können und vor allem nicht mit Bitmasken.

Jedes der Dinge, die Sie erwähnt haben, können (und sollten) mit realen Spalten in der Datenbank gelöst werden, und diese sind viel selbstdokumentierender als "Bit 5 des Feldes BitMaskOptions".

Answer 2

Eine dedizierte Spalte ist ist besser, weil es zweifellos offensichtlicher und weniger fehleranfällig ist. SQL Server already stores BIT columns efficiently, Leistung ist kein Problem. Das einzige Argument, das ich für eine Bitmaske sehen konnte, ist, dass ich das DB-Schema nicht jedes Mal ändern muss, wenn Sie ein neues Flag hinzufügen, aber wirklich, wenn Sie neue Flags hinzufügen, dann ist oft etwas nicht in Ordnung.

Answer 3

Nein, es ist nicht einmal entfernt eine gute Idee IMO. Jede Spalte sollte ein einzelnes Konzept und einen Wert darstellen. Bitmasken weisen alle Arten von Leistungs- und Wartungsproblemen auf. Wie verstehen neue Entwickler, was jedes einzelne Bit bedeutet? Wie verhindert man, dass jemand versehentlich die Bedeutung der Reihenfolge der Bits vermischt?

Es wäre besser, eine Viele-zu-Viele-Beziehung oder separate Spalten statt einer Bitmaske zu haben. Sie können darauf indizieren, die referenzielle Integrität aktivieren (abhängig vom Ansatz), einfach neue Elemente hinzufügen und die Reihenfolge der Ergebnisse ändern, um sie an verschiedene Berichte anzupassen.