J'ai une colonne supprimée dans ma table. Sur chaque déclaration SQL, je vérifie si ce drapeau est null. Est-ce que quelqu'un veut supprimer des entrées, le drapeau est défini sur l'horodatage actuel.
En cas de restauration des entrées, cet horodatage est utilisé pour les restaurer. Ceci est le seul cas d'utilisation lorsque la valeur de cette colonne sera utilisée.
Dans tous les autres cas, il est seulement important de savoir s'il est nul ou que ce n'est pas nul.
à l'avenir, la table peut et contiendra des millions de lignes.
est-il utile de créer un index sur cette colonne? Parce que 99% des déclarations et des cas d'utilisation ne se soucient pas de la valeur.
MySQL optimise-t-il des conditions nulles et donc un index n'est pas nécessaire?
3 Réponses :
Vous ne pouvez pas créer une table "archive" et stocker des lignes supprimées avec leur horodatage. Si l'utilisateur souhaite restaurer une ligne, vous devez le transférer des archives à votre table principale.
et vous n'avez pas à vérifier "le drapeau n'est pas null" dans chaque requête
C'est une suggestion extrêmement naïve. Vous allez casser toutes les clés étrangères ou avoir un mal de tête sérieux qui se reproduit dans les tables d'archives. Vous obtiendrez également une clé primaire différente de la séquence sur Undelete, qui enfreindrait les URI existantes, à moins que vous n'utilisiez exclusivement des limaces.
Un espace supplémentaire est nécessaire, oui. Mais qu'en est-il de la vitesse? Est-il plus rapide de vérifier est null ou de vérifier = 0? Ou est-ce seulement une optimisation marginale?
N'utilisez jamais NULL? Qu'en est-il d'importer des données dans une colonne qui doit être 1 ou 0, mais vous devez également savoir si aucune valeur n'était jamais présente? NULL existe pour une raison et devrait être utilisé quand il a du sens. Ne pas utiliser NULL peut causer de graves problèmes lors de la vérification de l'intégrité des données, en particulier sur des colonnes de texte pouvant contenir des espaces vides. J'utilise toujours NULL comme une valeur par défaut, sauf décision convaincante de ne pas l'utiliser.
Un index sur «supprimé» indexera également les valeurs nulles et permettra ainsi de rechercher des recherches plus rapides de non-NULL / NULL
Je pense que cela suffira dans ce cas et ne causera pas trop de frais généraux, puisque l'horodatage est défini sur la suppression et que celle-ci ne changera pas beaucoup de choses. (Le contraire: à l'aide d'un horodatage modifié qui change tout le temps et que cela est parfois défini sur NULL, causerait de régler l'index à chaque fois qu'un enregistrement est modifié. Ce n'est peut-être pas optimal. Ce n'est pas le cas ici.) / p>
(En outre, mais je ne sais pas si l'indexeur est suffisamment intelligent pour en tirer parti, les changements attendus vont toujours aux extrémités de l'index, soit à l'extrémité NULL, soit à la fin "la plus récente" .)
Bien sûr, profil (à la fois des temps d'exécution de la requête et de l'espace de stockage si important) pour savoir s'il y a des problèmes réels découlant de cela.