Dev Faq
12
votes

Quelle est l'importance de sélectionner le plus petit type de données possible lors de la conception d'une base de données?

Quelle différence utilise-t-elle en utilisant tinyint ou smallint (le cas échéant) au lieu de int faire? Ou restreindre un champ char sur les caractères minimum nécessaires?

Ces choix affectent-ils les performances ou juste alloué de l'espace?

2 commentaires

Quelle est votre plate-forme cible? Combien d'enregistrements avez-vous l'intention de stocker? Des informations comme ceci incluses dans votre question peuvent aider à guider une réponse appropriée.

Je n'ai pas de besoin spécifique (encore, pourrait avoir bientôt) je veux juste apprendre

4 Réponses :

5
votes

Oui, cela affecte les performances aussi.

Si les index sont plus grands, il faut plus de temps pour les lire du disque, et moins peut être mis en cache en mémoire.

0 commentaires
0
votes

les deux, dans certains cas. Mais imo, c'est plus une question de conception que des considérations de performance et de stockage. La raison pour laquelle vous ne faites pas tout ce que vous ne faites pas tout varchar (...) est dû au fait que cela ne reflète pas avec précision quel type de données doit être stockée là-bas et réduit l'intégrité et la sécurité de votre type de données. < / p>

0 commentaires
7
votes

sur un champ indexé avec une table significativement grande, la taille de votre champ peut apporter un effet important sur la performance. Sur un champ non indexé, ce n'est pas presque aussi important que cela doit toujours écrire les données supplémentaires.

Cela dit, le temps d'arrêt d'un redimensionnement d'une grande table peut être plusieurs minutes ou plusieurs heures, même si vous ne les rendez pas plus petit que vous ne l'imaginez jamais besoin.

0 commentaires
2
votes

J'ai fréquemment vu ces trois défauts de conception de schéma, causant des problèmes:

  1. Un champ de Varcharchar (n) a été créé avec n Seulement suffisamment grand pour l'échantillon de données que le concepteur avait tiré, pas la population mondiale: amende dans des tests unitaires, des troncations silencieuses dans le monde réel.
  2. A Varchar (N) Utilisé lorsque les données sont une taille fixe. Cela masque des bugs de données.
  3. Un char (n) utilisé pour des données de longueur variable. Ceci fournit des améliorations de performance (en permettant aux données de s'asseoir en ligne dans la ligne sur disque, mais tout le code client (et divers processus / vues stockés) doit faire face aux problèmes de rembourrage des espaces (et souvent, ils ne le font pas). Le rembourrage des espaces blanche peut être difficile à suivre, car les espaces ne se présentent pas trop bien, et diverses banques / clients SQL les suppriment.

    Je n'ai jamais vu un bien intentionné (c'est-à-dire non seulement à l'aide de Varchar (255) pour tous les cols), mais la sélection conservatrice de la mauvaise taille des données entraîne des problèmes de performance significatifs. En signifiant, je veux dire facteur de 10. Je vois régulièrement des défauts de conception algorithmiques (index manquants, envoi de trop de données sur le fil, etc.), causant des hits de performance beaucoup plus importants.

1 commentaires

Varcharne (255) doit être exactement aussi efficace que Varchar (10) car la taille est juste une taille maximale. MySQL n'utilise que le nombre d'octets nécessaires pour stocker le contenu. Ceci est différent d'un caractère où MySQL utilise exactement le nombre donné d'octets.

Articles qui pourrait vous intéresser :

phpMyAdmin - Erreur paramètre de format incorrect
Système d'exploitation non pris en charge pour MySQL Workbench - Windows 7
Problème de jointure sql, impossible de récupérer les enregistrements de la table a qui correspondent à une condition de la table b et les enregistrements restants de la table a
Laravel UUID comme clé primaire et ID comme clé étrangère