2009-01-23 9 views

Répondre

6

Cela dépend s'il est toujours raisonnable de stocker une grande quantité de données dans la colonne particulière.

Si vous déclarez une colonne qui ne stocker correctement les données beaucoup (à savoir un premier nom de l'employé comme VARCHAR (1000)), vous vous retrouvez avec une variété de problèmes

  1. Beaucoup, sinon la plupart des API clientes (c.-à-d. pilotes ODBC, pilotes JDBC, etc.) allouer des tampons de mémoire sur le client qui sont assez grands pour stocker la taille maximale d'une colonne particulière. Ainsi, même si la base de données ne doit stocker que les données réelles, vous pouvez augmenter considérablement la quantité de mémoire utilisée par l'application cliente.
  2. Vous perdez la possibilité de piloter des règles de validation de données (ou de communiquer des informations sur les données) à partir de la définition de la table. Si la base de données autorise des prénoms de 1000 caractères, chaque application qui interagit avec la base de données finira probablement par avoir ses propres règles sur la taille d'un nom d'employé. Si cela n'est pas atténué en plaçant une couche de procédure stockée entre toutes les applications et les tables, cela conduit généralement à diverses applications ayant diverses règles. La loi de Murphy stipule que si vous autorisez 1000 caractères, quelqu'un finira par stocker 1000 caractères dans la colonne, ou au moins une valeur suffisamment grande pour causer des erreurs dans une ou plusieurs applications (c.-à-d. champ peut afficher 1000 caractères).
0

Vous pourriez être l'ajout d'un risque de casser votre demande si une grande quantité de données se sont en quelque sorte (comme à partir d'une interface externe) et votre application ne sont pas conçus pour gérer.

Comme une bonne conception, vous devriez toujours limiter la taille des champs à une valeur réaliste.

4

Dépend du SGBDR. IIRC, MySql alloue un overhead de 2 octets pour les varchars> 255 caractères (pour suivre la longueur de varchar). MSSQL < = 2000 vous permettrait d'allouer une taille de ligne> 8060 octets, mais échouerait si vous essayiez d'INSÉRER ou de METTRE À JOUR une ligne qui dépassait réellement 8060 octets. SQL 2005 [1] autorise l'insertion, mais va allouer une nouvelle page pour le débordement et laisser un pointeur derrière. Ceci, évidemment, a un impact sur la performance. [1] varchar (max) est un cas particulier, mais allouera également une page de débordement si la longueur du champ est> 8000 ou la ligne> 8060. Ceci est avec les valeurs par défaut de MSSQL, et le comportement peut changer avec les grands types dans l'option de ligne de données.

Questions connexes