web-dev-qa-db-fra.com

varchar (255) ou varchar (256)?

Dois-je utiliser varchar(255) ou varchar(256) lors de la conception des tables? J'ai entendu qu'un octet est utilisé pour la longueur de la colonne ou pour stocker des métadonnées.

Est-ce plus important à ce stade?

J'ai vu quelques articles sur Internet, mais ils s'appliquent à Oracle et à MySQL.

Nous avons Microsoft SQL Server 2016 Enterprise Edition, comment s'applique-t-il à cet environnement?

Maintenant, disons par exemple, que se passe-t-il si je dis à mes clients de conserver, par exemple, une description textuelle de 255 caractères au lieu de 256, y a-t-il une différence? Ce que j'ai lu "Avec une longueur maximale de 255 caractères, le SGBD peut choisir d'utiliser un seul octet pour indiquer la longueur des données dans le champ. Si la limite était de 256 ou plus, deux octets seraient nécessaires." Est-ce vrai?

sql-serverdatabase-designsql-server-2016varcharenterprise-edition
22
user129291

D'autres ont déjà souligné que le nombre d'octets requis pour stocker la longueur est fixe. Je voulais me concentrer sur cette partie de votre question:

Est-ce plus important à ce stade?

Votre question est étiquetée avec l'édition entreprise, ce qui signifie généralement que vous aurez une bonne quantité de données. Souvent, les différences d'un octet par ligne n'ont pas vraiment d'importance en pratique. Par exemple, le tableau suivant avec une colonne VARCHAR(255) entièrement remplie occupe 143176 Ko d'espace sur le disque:

DROP TABLE IF EXISTS dbo.V255_FULL;

CREATE TABLE dbo.V255_FULL (
    ID1 BIGINT NOT NULL,
    ID2 BIGINT NOT NULL,
    V255 VARCHAR(255)
);

INSERT INTO dbo.V255_FULL WITH (TABLOCK)
SELECT TOP (500000) 0, 0, REPLICATE('A', 255)
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

EXEC sp_spaceused 'V255_FULL';

Résultats:

╔═══════════╦══════════════════════╦═══════════╦═══════════╦════════════╦════════╗
║   name    ║         rows         ║ reserved  ║   data    ║ index_size ║ unused ║
╠═══════════╬══════════════════════╬═══════════╬═══════════╬════════════╬════════╣
║ V255_FULL ║ 500000               ║ 143176 KB ║ 142888 KB ║ 8 KB       ║ 280 KB ║
╚═══════════╩══════════════════════╩═══════════╩═══════════╩════════════╩════════╝

Créons une deuxième table avec une colonne VARCHAR(256) entièrement remplie. Cela va prendre au moins un octet de plus par ligne, non?

DROP TABLE IF EXISTS dbo.V256_FULL;

CREATE TABLE dbo.V256_FULL (
    ID1 BIGINT NOT NULL,
    ID2 BIGINT NOT NULL,
    V256 VARCHAR(256)
);

INSERT INTO dbo.V256_FULL WITH (TABLOCK)
SELECT TOP (500000) 0, 0, REPLICATE('A', 256)
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

EXEC sp_spaceused 'V256_FULL';

Résultats:

╔═══════════╦══════════════════════╦═══════════╦═══════════╦════════════╦════════╗
║   name    ║         rows         ║ reserved  ║   data    ║ index_size ║ unused ║
╠═══════════╬══════════════════════╬═══════════╬═══════════╬════════════╬════════╣
║ V256_FULL ║ 500000               ║ 143176 KB ║ 142888 KB ║ 8 KB       ║ 280 KB ║
╚═══════════╩══════════════════════╩═══════════╩═══════════╩════════════╩════════╝

Il se trouve que les deux tables occupent la même quantité d'espace. Le même nombre de lignes tient sur chaque page de 8 Ko. C'est formidable que vous souhaitiez passer du temps à optimiser votre application, mais je pense que vous feriez mieux de vous concentrer sur différents domaines.

18
Joe Obbish

La taille déclarée du varchar n'a aucun impact sur les performances. Les données peuvent être réellement stockées en tant que magasin de lignes avec compression de page ou compression de ligne. En tant que magasin de colonnes en cluster ou en tant que table optimisée en mémoire. Chacun d'eux aura des compromis de performances différents, mais il importe peu que vous déclariez un varchar (255) ou varchar (256).

7
David Browne - Microsoft