J'essaie de comprendre le meilleur moyen de gérer les colonnes qui sont principalement vides en termes de espace disque et Merci.
3 Réponses :
La réponse simple est peut-être (bien que cela ne soit pas d'importance), NULLS peut prendre moins d'espace disque, bien que l'économie d'espace soit probablement minuscule (même si minuscules économies s'ajoutera).
À moins que l'espace disque est très contraint, je ne m'inquiéterais pas à ce sujet (l'espace disque est beaucoup moins cher que le temps de programmeur).
De plus, NULL et 0 (ou '') sont sémantiquement différents, ne devraient donc pas être utilisés de manière interchangeable, certainement pas pour un gain de performance théorique (ou très petit).
voir cette question pour plus de détails.
Je ne pense pas que l'indexation soit grandement touchée, il peut y avoir une légère amélioration de la vitesse.
Voir Cette question pour plus de détails.
Cette question traite spécifiquement avec MySQL et Null Performances. < / p>
Pourquoi une nulle prendrait-elle moins d'espace qu'un champ Varchark vide?
@Gavintowey - Désolé, je pensais à Varchars avec des données, je vais modifier ma réponse, ils avaient probablement au maximum 1 prenez 1 caractères.
Non, à l'aide de NULL ne prendra pas moins d'espace qu'un A de sorte que VARCHAR code> ou int code>. En fait, cela peut prendre plus fort> espace. Voici pourquoi: Varchar code> est stocké en tant que valeur + valeur. Le nombre d'octets utilisés pour la taille dépend du stockage maximal du Varchar code>. varchar (255) code> nécessite un octet, varchar (65536) code> nécessite deux octets et ainsi de suite. P> varchar (255) La colonne prend un octet même si vous stockez une chaîne vide. Le tableau suivant prendrait un minimum d'un octet par ligne (plus d'autres frais généraux possibles en fonction du moteur de stockage). P> CREATE TABLE sample (
a VARCHAR(255) NULL
);
Une bonne réponse, est-ce que cela s'applique à MySQL & MS SQL Server?
Je sais que cela est vrai pour MySQL, mais je ne prétends pas à connaître les autres - Cette réponse semble indiquer qu'il est similaire: Stackoverflow.com/Questtions/3731172/...
@Gavintowey Bonne réponse, mais je suppose que le masque que vous avez mentionné aide MySQL gérer les index plus efficacement? Si oui, cela n'entraînerait-il pas moins d'espace dans des cas il y a un index sur cette colonne?
Ce n'est pas le cas. Je ne sais pas exactement ce qu'il fait en interne, mais ce test rapide montre que NULL dans un index ne prend pas moins d'espace. Pastebin.ca/2247977
Cela dépend.
Si vous avez une table à largeur fixe (no dans une table de largeur variable, un Alors supposons que vous avez une liste de personnes où seulement quelques-uns d'entre eux vous avez la date de naissance. donc au lieu de vous pouviez faire et interroger les données avec une jointure gauche. S'il y a des applications qui doivent accéder à la table dans l'ancien format, vous pouvez définir une vue. varchar , varbinaire , blob ou ), il ne fera probablement aucune différence. null consommera probablement autant d'espace qu'un Varchar < /code >.
Vous avez presque toutes les valeurs null et seulement très peu contiennent des données, vous pouvez créer une table séparée que vous adhérez à.
éventuellement un dupliqué
@Thanga Merci pour la Ref, il est similaire, mais je suis intéressé d'entendre parler de l'espace disque et des implications de la construction d'index. Clarifiera
En plus de ma réponse ci-dessous, mon conseil est que cela ressemble à un cas d'une "optimisation prématurée", cela ne vaut pas vraiment votre temps pour vous inquiéter. Il suffit de concevoir le schéma qui a du sens. Je vous garantissons que ce ne sera pas votre plus grand goulot d'étranglement.