Je viens dans une base de données où tous les caractères des colonnes en fonction ont leur taille spécifiée par multiples de 8 (par exemple, Nom d'utilisateur = varchar (32), Forename = nvarchar (128), etc.) Cela aurait-il une incidence sur la performance de la base de données ou est-ce complètement inutile?la taille des colonnes de base de données pour les données à base de caractères
Merci.
N.B. C'est dans une base de données SQL 2000.
Puisqu'ils sont VARchars l'espace réel utilisé est basé sur le contenu. Je commencerais à m'inquiéter s'ils étaient CHARs.
-Edoode
Cela me semble une optimisation prématurée.
Je ne pense pas que cela changera les performances de la base de données.
Il est probablement juste une habitude de certains développeurs de la vieille école. Comme il est dit - varchar est aussi long qu'il doit être, donc 32 ou 33 n'a pas d'importance quand la longueur de la chaîne est par exemple 22.
"Cela aurait-il une incidence sur les performances de la base de données ou est-il complètement inutile?"
Il a peu d'incidence sur les performances (pas de nul, mais peu). Cela peut avoir un impact sur l'allocation d'espace disponible, car la taille de ligne la plus grande peut être assez importante avec ce schéma. Peu de lignes par page peuvent ralentir les extractions de grandes tables.
La différence, cependant, est généralement microscopique par rapport à l'indexation incorrecte.
Et obtenir les tailles "correctes" ne vaut pas le temps. Dans les temps anciens, les DBA de la vieille école ont sué tous les personnages. Les disques étaient chers, et chaque octet avait un réel impact sur les coûts.
Maintenant que le disque est vraiment pas cher, le temps de DBA gaspillé en plus épiloguer tailles coûte plus cher que le disque.
Auriez-vous le même souci si elles étaient tous les multiples de 5 ou 10, qui est ce qui se passe dans le cas normal.?
Je ne l'ai jamais vu faire une différence dans le stockage de la table, les jointures ou les opérations de base.
Mais je l'ai vu faire une différence où le traitement de chaîne est impliqué.
Dans SQL Server 2005, le seul cas que j'ai vu où la taille varchar fait des différences significatives est lorsque les choses sont transtypées en varchar (MAX) ou en UDF. Il semble y avoir une différence là - par exemple, j'ai un système/processus que je porte avec un certain nombre de colonnes clés qui doivent être concaténées ensemble dans un autre pseudo keyfield (jusqu'à ce que je suis capable de refactoriser cette abomination) et le Requête effectuée de façon significative, le résultat est obtenu sous la forme de varchar (45) dès que possible dans les CTE intermédiaires ou les requêtes imbriquées.
J'ai vu des cas où un UDF en prenant et en retournant un varchar (MAX) fonctionne significativement plus mal que l'on prend et retourne varchar (50), disons. Par exemple, une fonction de rognage ou de rembourrage que quelqu'un (peut-être moi!) Essayait de faire preuve d'avenir. varchar (MAX) a sa place, mais selon mon expérience, cela peut être dangereux pour la performance.
Je ne pense pas que je PROFILES une différence entre varchar (50) et varchar (1000).