Beaucoup de schémas de base de données semblent suivre la norme suivante:
(2 ^ n) -1 pour les grands champs: ... alors Je comprends pourquoi les numéros de (2 ^ n) -1 sont utilisés, Ce que je ne comprends pas, c'est pourquoi il n'est pas nécessaire de poursuivre la tendance aux petits champs. par exemple par exemple est une raison de ceci ou est-ce que les retours ont diminué trop loin?
6 Réponses :
Je ne peux pas dire comme je l'ai vu la tendance "-1" utilisée différemment pour des champs plus petits / plus grands. Cependant, je pense que tout n'est rien de plus que le développeur / DBA TOC. Vouloir toujours des chiffres «ronds» lorsqu'ils devraient vraiment faire des décisions de longueur sur le terrain basées sur des règles d'entreprise plutôt que sur «la jolie»
En fait, c'est la première fois que j'ai entendu parler d'une telle "tendance". Mes champs Varcharis sont toujours aussi longtemps que j'en ai besoin d'être.
Je dirais qu'il n'y a pas de raison particulière derrière cela. Juste la préférence du développeur.
Je ne peux pas imaginer un instant pourquoi ils dimensionnent les champs de cette façon de compter 2 ^ n ou 2 ^ n-1. À partir d'une perspective SQL Server, cela ressemble plus à une idée fausse sur la manière dont SQL stocke ces données au niveau de la page que sur une raison spécifique.
Je paierais plus d'attention aux types, potentiels de stockage de page (SLOB / LOB) et lignes / page + répondant aux besoins de l'entreprise avec dimensionnement, qu'une formule basée sur l'utilisation de 2 ^ N, etc.
Je pense que ce ne sont que des programmeurs choisissant un numéro de l'air quand cela n'a pas vraiment d'importance.
Si vous deviez mettre une limite sur le champ "Notes", par exemple, un non programmeur choisirait probablement 100 ou 200 caractères en tant que numéro rond, tandis qu'un programmeur pourrait penser à 127 ou 255 en tant que nombre rond.
Je me souviens de l'ancien temps, lorsque vous utilisez une longueur de 2 ^ N, il y avait mieux l'alignement des blocs sur disque ou mémoire. Bloc aligné étaient plus rapides. Aujourd'hui, les tailles "Block" sont plus grandes et la mémoire et le disque sont suffisamment rapides pour ignorer l'alignement, Except pour de très grands blocs qui sont. (Tout ce que "très grand" signifie aujourd'hui ....)
De nos jours, il est juste traditionnel de le faire.
Et une autre raison, mon soyez le fameux dicton: Il n'y a que 10 types de personnes: ceux qui peuvent binaires et les autres.
et 2 ^ n -1 sont des candidats pour Mersenne Primes. Donc, c'est aussi geek ...
Pour le problème de 2 ^ n -1: de nombreuses langues de programmation utilisent un octet nul pour mettre fin à une valeur de chaîne (Pascal était une valeur qui ne le fait pas, mais stocké la longueur au premier octet de la chaîne), vous avez donc besoin d'un octet plus à stocker la chaîne. Cela pourrait donc être une raison d'utiliser un de moins aussi.
Non seulement les retours sont diminués, mais si vous définissez des types de chaîne avec des limites arbitraires, vous êtes beaucoup plus susceptible de causer un problème que de résoudre un.
Si c'est vraiment une contrainte commerciale, utilisez le type de texte (ou similaire) et une contrainte de contrôle sur la longueur et choisissez le numéro en fonction de la contrainte d'entreprise que vous essayez d'appliquer.
Le SGBD implémentera probablement le stockage pour le type de texte identique à Varcharne (X) de toute façon. Si ce n'est pas le cas, et vous vous souciez vraiment, vous devez étudier les stratégies de stockage internes de votre système particulier et déterminez s'il existe un avantage pour Varchar ou non.