drapeau 'actif' ou pas?

Question

OK, pratiquement toutes les applications basées sur une base de données doivent traiter avec "non actif". enregistrements. Suppression douce ou marquage de quelque chose comme "à ignorer". Je suis curieux de savoir s'il existe des idées alternatives radicales sur une colonne "active" (ou une colonne de statut).

Par exemple, si j'avais une liste de personnes

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

Cela signifie que pour obtenir une liste des personnes actives, vous devez utiliser

SELECT * FROM people WHERE active=True;

Quelqu'un suggère-t-il que les enregistrements non actifs seraient déplacés vers une table distincte et où une union est faite pour joindre les deux?

Curiosité frappe ...

MODIFIER: Je devrais préciser, j'aborde cette question d'un point de vue puriste. Je peux voir à quel point l'archivage des données peut être nécessaire pour de grandes quantités de données, mais ce n'est pas de là que je viens. Si vous faites un SELECT * FROM personnes, il serait logique que ces entrées soient dans un sens "actives"

Merci

Answer 1

Vous partitionnez la table sur l'indicateur actif, de sorte que les enregistrements actifs se trouvent dans une partition et les enregistrements inactifs dans l'autre partition. Ensuite, vous créez une vue active pour chaque table sur laquelle le filtre actif est automatiquement placé. Le moteur de requête de base de données limite automatiquement la requête à la partition contenant les enregistrements actifs, ce qui est beaucoup plus rapide que l'utilisation même d'un index sur cet indicateur.

Voici un exemple de création d'une table partitionnée dans Oracle. Comme Oracle n'a pas de type de colonne booléen, j'ai modifié votre structure de table à des fins Oracle.

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)
);

Si vous le souhaitez, vous pouvez placer chaque partition dans différents espaces de table. Vous pouvez également partitionner vos index.

Incidemment, cela semble être une répétition de this question, en tant que débutant, je dois poser la question suivante: quelle est la procédure à suivre pour traiter les doublons inattendus?

Modifier: Comme demandé dans les commentaires, donnez un exemple de création d'une table partitionnée dans Oracle

Answer 2

Eh bien, pour vous assurer de ne dessiner que des enregistrements actifs dans la plupart des situations, vous pouvez créer des vues contenant uniquement les enregistrements actifs. De cette façon, il est beaucoup plus facile de ne pas laisser de côté la partie active.

Answer 3

Nous utilisons un enum ("ACTIVE", "INACTIF", "SUPPRIMÉ") dans la plupart des tableaux, nous avons donc un indicateur à 3 voies. Je trouve que cela fonctionne bien pour nous dans différentes situations. Votre kilométrage peut varier.

Answer 4

Déplacer des objets inactifs est généralement une idée stupide. Il y a beaucoup de frais généraux avec beaucoup de potentiel de bugs, tout devient plus compliqué, comme le désarchivage des données, etc. Que faites-vous avec les données associées? Si vous déplacez tout cela aussi, vous devez modifier chaque requête. Si vous ne le déplacez pas, quel avantage espériez-vous obtenir?

Cela nous amène au point suivant: POURQUOI voulez-vous le déplacer? Une table correctement indexée nécessite une recherche supplémentaire lorsque la taille double. Toute amélioration des performances sera forcément négligeable. Et pourquoi y penseriez-vous jusqu’à un avenir lointain, lorsque vous rencontrez des problèmes de performances?

Answer 5

Je pense que le voir strictement comme une donnée, la manière dont il est montré dans le post original est appropriée. L’élément de drapeau actif dépend directement de la clé primaire et doit figurer dans la table.

Cette table contient des données sur les personnes, quel que soit le statut actuel de leurs données.

Answer 6

Le drapeau actif est un peu moche, mais il est simple et fonctionne bien.

Vous pouvez les déplacer vers une autre table, comme vous l'avez suggéré. Je suggère de regarder le pourcentage d'enregistrements actifs / inactifs. Si vous avez plus de 20 ou 30% d'enregistrements inactifs, vous pouvez envisager de les déplacer ailleurs. Sinon, ce n'est pas grave.

Answer 7

Oui, nous le ferions. Nous avons actuellement le "actif = 'T / F'" colonne dans beaucoup de nos tableaux, principalement pour montrer la «dernière» ligne. Lorsqu'une nouvelle ligne est insérée, la ligne T précédente est marquée F pour la conserver à des fins d'audit.

Nous passons maintenant à une approche à deux tables: lorsqu'une nouvelle ligne est insérée, la ligne précédente est déplacée vers une table d'historique. Cela nous donne de meilleures performances dans la majorité des cas - en regardant les données actuelles.

Le coût est légèrement supérieur à l'ancienne méthode. Auparavant, vous deviez mettre à jour et insérer, maintenant vous devez insérer et mettre à jour (c'est-à-dire qu'au lieu d'insérer une nouvelle ligne T, vous modifiez la ligne existante avec toutes les nouvelles données), le coût consiste donc simplement à transmettre toute une ligne de données au lieu de transmettre uniquement les modifications. Cela n’aura guère d’effet.

L’avantage en termes de performances est que l’indice de votre table principale est nettement plus petit et que vous pouvez optimiser vos espaces de tables (ils ne se développeront pas autant!)

Answer 8

Les indicateurs binaires comme celui-ci dans votre schéma sont une mauvaise idée. Considérons la requête

SELECT count(*) FROM users WHERE active=1

Ça a l'air assez simple. Mais que se passe-t-il lorsque vous avez un grand nombre d'utilisateurs, si nombreux qu'il est nécessaire d'ajouter un index à cette table? Encore une fois, ça a l'air simple

ALTER TABLE users ADD INDEX index_users_on_active (active)

SAUF !! Cet index est inutile car la cardinalité sur cette colonne est exactement deux! Tout optimiseur de requêtes de base de données ignorera cet index en raison de sa faible cardinalité et effectuera une analyse de la table.

Avant de remplir votre schéma avec des indicateurs utiles, déterminez la manière dont vous allez accéder à ces données.

https://stackoverflow.com/questions/108503/mysql-advisable-number -de-lignes

Answer 9

Nous utilisons assez souvent des drapeaux actifs. Si votre base de données doit être très volumineuse, la valeur de la migration des valeurs inactives vers une table distincte peut cependant être utile.

Vous n’auriez alors besoin d’une union des tables que si vous souhaitez voir tous les enregistrements, actifs ou inactifs.

Answer 10

Dans la plupart des cas, un champ binaire indiquant la suppression suffit. Il existe souvent un mécanisme de nettoyage qui supprime les enregistrements supprimés après un certain temps. Vous pouvez donc souhaiter démarrer le schéma avec un horodatage supprimé.

Answer 11

Passer à une table séparée et les remettre en place prend du temps. Selon le nombre d'enregistrements déconnectés et la fréquence à laquelle vous devez les récupérer, cela peut être une bonne idée ou non.

Si la plupart ne reviennent pas une fois enterrés et s'ils ne sont utilisés que pour des résumés / rapports / quoi que ce soit, votre table principale sera alors plus petite, les requêtes plus simples et probablement plus rapides.

Answer 12

Nous utilisons les deux méthodes pour traiter les enregistrements inactifs. La méthode que nous utilisons dépend de la situation. Pour les enregistrements qui sont essentiellement des valeurs de recherche, nous utilisons le champ de bit actif. Cela nous permet de désactiver les entrées afin qu'elles ne soient pas utilisées, mais nous permet également de maintenir l'intégrité des données avec les relations.

Nous utilisons la table "déplacer vers la table de séparation". méthode où les données ne sont plus nécessaires et qui ne font pas partie d’une relation.

Answer 13

La situation dicte vraiment la solution, à mon avis:

Si la table contient des utilisateurs, plusieurs "indicateur". les champs pourraient être utilisés. Un pour Supprimé, Désactivé, etc. Ou si l’espace est un problème, un indicateur pour désactivé suffira, puis supprimez la ligne si elle a été supprimée.

Cela dépend également des politiques de stockage des données. S'il existe des politiques pour conserver les données archivées, un tableau séparé sera probablement nécessaire après une très longue période.

Answer 14

Non - c’est une chose assez commune - quelques variations en fonction des besoins spécifiques (mais vous les avez déjà abordées):

1) Si vous vous attendez à disposer de tout un tas de données, telles que plusieurs téraoctets ou plus, n’est pas une mauvaise idée d’archiver immédiatement les enregistrements supprimés. Vous pouvez toutefois utiliser une combinaison de marquages ??comme étant supprimés, puis de la copie dans des tables archivées. / p>

2) Bien sûr, l’option de suppression définitive d’un enregistrement existe toujours - bien que nous, les développeurs, ayons tendance à être des donneurs de données -, je vous suggère d’examiner le processus commercial et de décider s’il est maintenant nécessaire de conserver les données. Données - s'il y en a - faites-le ... s'il n'y en a pas - vous devriez probablement vous sentir libre de simplement jeter les choses ... encore une fois, selon le scénario commercial spécifique.

Answer 15

D'un point de vue puriste, le modèle réel ne fait pas la différence entre une vue et une table - les deux sont des relations. Ainsi, l’utilisation d’une vue utilisant le discriminateur est parfaitement pertinente et valable à condition que les entités soient correctement nommées, par exemple. Personne / ActivePerson.

En outre, d’un point de vue puriste, la table doit être nommée personne, et non des personnes, car le nom de la relation reflète un tuple, et non l’ensemble.

Answer 16

En ce qui concerne l'indexation du booléen, pourquoi pas:

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

Cela n'améliorerait-il pas la recherche?
Cependant, je ne sais pas dans quelle mesure cette réponse dépend de la plate-forme.