`Aktiv‘ Flag oder nicht?

Question

OK, also praktisch jede Datenbank-basierte Anwendung hat mit „nicht aktiv“ Aufzeichnungen beschäftigen. Entweder, Soft-Deletionen oder Kennzeichnung etwas wie „ignoriert werden“. Ich bin gespannt, ob es irgendwelche radikalen Alternativen Gedanken auf einer `aktiven‘ Spalte (oder eine Statusspalte).

Zum Beispiel, wenn ich eine Liste von Personen habe

CREATE TABLE people (
  id       INTEGER PRIMARY KEY,
  name     VARCHAR(100),
  active   BOOLEAN,
  ...
);

Das bedeutet, dass eine Liste der aktiven Menschen zu bekommen, müssen Sie verwenden

SELECT * FROM people WHERE active=True;

Hat jemand vorschlagen, dass nicht aktive Datensätze in eine separaten Tabelle weg bewegt werden würde und wo eine sachgemäße UNION getan wird, um die beide zu verbinden?

Curiosity auffällig ...

EDIT: Ich soll klar machen, ich bin auf diesem von einer puristischen Perspektive kommen. Ich kann sehen, wie die Datenarchivierung kann für große Datenmengen notwendig sein, aber das ist nicht, wo ich herkomme. Wenn Sie eine SELECT * FROM Menschen tun würde es Sinn für mich, dass die Einträge in einem gewissen Sinne „aktiv“ sind

Danke

Answer 1

partitionieren Sie die Tabelle auf dem Aktiv-Flag, so dass aktive Datensätze in einer Partition sind, und inaktive Datensätze sind in der anderen Partition. Dann Sie eine aktive Ansicht für jede Tabelle erstellen, die automatisch den aktiven Filter auf sie. Der Datenbank-Abfrage-Engine beschränkt automatisch die Abfrage an die Partition, die die aktiven Aufzeichnungen in ihm hat, die viel schneller ist als auch einen Index für diese Flagge verwendet wird.

Hier ist ein Beispiel dafür, wie eine partitionierten Tabelle in Oracle zu erstellen. Oracle nicht boolean Spaltentypen haben, also habe ich Ihre Tabellenstruktur für Oracle Zwecke modifiziert.

CREATE TABLE people
(
   id       NUMBER(10),
   name     VARCHAR2(100),
   active   NUMBER(1)
)
PARTITION BY LIST(active)
(
   PARTITION active_records VALUES (0)
   PARTITION inactive_records VALUES (1)
);

Wenn Sie Sie wollten in verschiedenen Tablespaces jede Partition setzen könnte. Sie können auch Ihre Indizes als auch partitionieren.

Übrigens scheint dies eine Wiederholung von this Frage, als Neuling ich fragen müssen, was ist das Verfahren mit unbeabsichtigten Duplikaten auf dem Umgang?

Edit: Wie in den Kommentaren aufgefordert, ein Beispiel zur Aufnahme einer partitionierten Tabelle in Oracle Erstellen

Answer 2

Nun, um sicherzustellen, dass Sie nur aktive Datensätze in den meisten Situationen ziehen, könnten Sie Ansichten erstellen, die nur die aktiven Datensätze enthalten. Auf diese Weise ist es viel einfacher, nicht den aktiven Teil auslassen.

Answer 3

Wir verwenden eine ENUM ( 'ACTIVE', 'INACTIVE', 'deleted') in den meisten Tischen, so dass wir tatsächlich eine 3-Wege-Flagge. Ich finde, es funktioniert gut für uns in verschiedenen Situationen. Ihre Ergebnisse können variieren.

Answer 4

inaktive Sachen Umzug ist in der Regel eine dumme Idee. Es ist eine Menge Aufwand mit vielen Potenzial für Fehler, alles komplizierter wird, wie dearchiviert das Zeug usw. Was tun Sie mit verwandten Daten? Wenn Sie alles, was zu bewegen, auch, müssen Sie jede einzelne Abfrage ändern. Wenn Sie es nicht bewegen, was den Vorteil erhofften Sie bekommen?

Das führt zum nächsten Punkt: Warum würden Sie es bewegen? Eine korrekt indiziert Tabelle erfordert eine zusätzliche Lookup, wenn die Größe verdoppelt. Jede Leistungsverbesserung gebunden ist vernachlässigbar. Und warum würden Sie denken sogar darüber, bis die ferne Zukunft Zeit, wenn Sie tatsächlich Performance-Probleme haben?

Answer 5

Ich denke, es streng als ein Stück Daten suchen, dann die Art und Weise, die in der ursprünglichen Nachricht angezeigt wird, ist richtig. Das Aktivflag Datenstück ist direkt abhängig von dem Primärschlüssel und soll in der Tabelle sein.

Diese Tabelle enthält Daten über Personen, unabhängig von dem aktuellen Stand ihrer Daten.

Answer 6

Die aktive Flagge ist eine Art von hässlich, aber es ist einfach und funktioniert gut.

Sie könnten sie an einem anderen Tisch bewegen, wie Sie vorgeschlagen. Ich würde vorschlagen, um den Prozentsatz des aktiven / inaktiven Datensätze suchen. Wenn Sie älter als 20 oder 30% inaktive Datensätze haben, dann können Sie prüfen, sie an anderer Stelle zu bewegen. Ansonsten ist es keine große Sache.

Answer 7

Ja, wir würden. Aktuell haben wir die „aktive =‚T / F‘“ -Spalte in vielen unserer Tabellen, vor allem die ‚neuesten‘ Reihe zu zeigen. Wenn eine neue Zeile eingefügt wird, wird die vorherige T Reihe F markiert es Zwecke, für Prüfung zu halten.

Nun, wir zu einem 2-Tabelle Ansatz bewegen, wenn eine neue Zeile eingefügt wird, wird die vorherige Zeile zu einer Historientabelle bewegt. Dies gibt uns eine bessere Leistung für die Mehrzahl der Fälle -. An der aktuellen Daten suchen

Die Kosten etwas mehr als die alte Methode ist, vorher musste man aktualisieren und einfügen, jetzt müssen Sie einfügen und aktualisieren (dh anstatt eine neue T Zeile einzufügen, ändern Sie die vorhandene Zeile mit allen neuen Daten), so dass die Kosten sind nur, dass in einer ganzen Reihe von Daten vorbei statt vorbei in nur die Änderungen. Das wird kaum Auswirkungen machen.

Der Performance-Vorteil ist, dass Ihre Haupttabelle des Index ist deutlich kleiner, und Sie können Ihre Tablespaces besser (sie wird nicht wachsen ganz so viel!)

Optimierung

Answer 8

Binary Flags wie dies in Ihrem Schema ist eine schlechte Idee. Betrachten Sie die Abfrage

SELECT count(*) FROM users WHERE active=1

Sieht einfach genug. Aber was passiert, wenn Sie eine große Anzahl von Benutzern haben, so viele, dass ein Index dieser Tabelle hinzugefügt erforderlich wäre. Auch hier sieht es gerade nach vorn

ALTER TABLE users ADD INDEX index_users_on_active (active)

AUSSER !! Dieser Index ist nutzlos, da die Mächtigkeit auf dieser Spalte genau zwei ist! Jede Datenbankabfrage Optimierers wird diesen Index ignorieren, weil es niedrige Mächtigkeit ist und machen Sie einen Table-Scan.

Vor dem Füllen Sie Ihr Schema mit hilfreichen Flags überlegen, wie Sie diese Daten zugreifen wollen.

https://stackoverflow.com/questions/108503/mysql-advisable-number -von-Reihen

Answer 9

Wir verwenden sehr oft aktiv Fahnen. Wenn Ihre Datenbank sehr groß sein wird, könnte ich den Wert bei der Migration von inaktiven Werten zu einer separaten Tabelle sehen, though.

Sie würden dann benötigen nur eine Vereinigung der Tabellen, wenn jemand will, um alle Datensätze sehen, die aktiv oder inaktiv ist.

Answer 10

In den meisten Fällen wird ein binäres Feld Löschung angibt, ist ausreichend. Oft gibt es einen sauberen Mechanismus, der die gelöschten Datensätze nach einer gewissen Zeit entfernen, so können Sie möchten das Schema mit einem gelöschten Zeitstempel starten.

Answer 11

Der Umzug in einer separaten Tabelle aus und bringen sie braucht Zeit sichern. Je nachdem, wie viele Datensätze offline gehen und wie oft müssen Sie sie zurück zu bringen, könnte es oder auch nicht eine gute Idee sein.

Wenn die meist nicht zurückkommen, sobald sie begraben sind, und sind nur für Zusammenfassungen / Berichte verwendet / was auch immer, dann wird es Ihre Haupttabelle kleine, Abfragen einfacher und wahrscheinlich schneller machen.

Answer 12

Wir verwenden beide Methoden für die inaktiven Datensätze handelt. Die Methode, die wir hängen von der Situation abhängig verwenden. Für Datensätze, die im Wesentlichen Nachschlagewerte werden, verwenden wir das Active-Bit-Feld. Dies erlaubt uns, Einträge zu deaktivieren, so dass sie verwendet wird, würde nicht, sondern erlaubt uns auch, die Datenintegrität mit Beziehungen aufrecht zu erhalten.

Wir verwenden die Methode „um Trennungstabelle bewegen“, wo die Daten nicht mehr benötigt werden, und die Daten sind nicht Teil einer Beziehung.

Answer 13

Die Situation wirklich diktiert die Lösung, dünkt mich:

Wenn die Tabelle Benutzer enthält, dann mehrere „Flag“ Felder verwendet werden könnten. Eine für gelöschte, Behinderte usw. Oder wenn Platz ein Problem ist, dann wird ein Flag für Behinderte würde genügen, und dann Löschen tatsächlich die Zeile, wenn sie gelöscht wurden.

Es hängt auch von Richtlinien zum Speichern von Daten. Wenn es Richtlinien für Daten archiviert zu halten, wird eine separate Tabelle würde höchstwahrscheinlich nach einer großen Länge der Zeit, die notwendig sein.

Answer 14

Nein - das ist eine ziemlich gemeinsame Sache - einige Variationen auf spezifische Anforderungen abhängig (aber Sie bereits bedeckte sie):

1) Wenn Sie eine ganze Reihe von Daten erwarten haben - wie mehrere Terabyte oder mehr - keine schlechte Idee, gelöschte Datensätze zu archivieren sofort -. Wenn Sie als gelöscht verwenden könnte eine Kombination Ansatz der Markierung dann Kopieren Tabellen archiviert

2) Natürlich zu hart die Option existiert ein Datensatz löscht noch - obwohl wir Entwickler neigen dazu, Daten-Pack-Ratten zu sein - ich schlage vor, dass Sie bei dem Geschäftsprozess aussehen sollen und entscheiden, ob es eine Notwendigkeit ist jetzt auch die halte Daten - wenn es - tun so ... wenn es nicht ist -. Sie sollten wahrscheinlich fühlen sich frei, einfach weg das Zeug zu werfen ..... wieder, entsprechend der spezifischen Business-Szenario

Answer 15

Von einer "puristischen Perspektive des realtional Modell unterscheidet nicht zwischen einer Ansicht und ein Tisch - beide Beziehungen sind. So dass die Verwendung einer Ansicht, die den Unterscheider verwendet, ist vollkommen sinnvoll und gültig, sofern die Einheiten zum Beispiel korrekt benannt Person / ActivePerson.

Auch von einer "puristischen Perspektive sollte die Tabelle Person benannt werden, die Menschen nicht wie der Name der Beziehung reflektiert ein Tupel, nicht der gesamte Satz.

Answer 16

Im Hinblick auf die Indizierung der boolean, warum nicht:

ALTER TABLE users ADD INDEX index_users_on_active (id, active) ;  

Wäre das nicht die Suche verbessern?
Allerdings weiß ich nicht, wie viel von dieser Antwort auf der Plattform abhängt.