SQL Server 8 Ko maximum par ligne?

Question

Je viens de lire le Maximum Capacity Specification for SQL Server 2008 et vu un maximum de 8060bytes par ligne? Qu'est-ce que ... Seulement 8Ko par rangée permis? (Oui, j'ai vu "manipulation de stockage de débordement de ligne" manipulation spéciale, je parle de comportement standard)

Ai-je mal comprendre quelque chose ici? Je suis sûr que je l'ai fait, car je suis sûr que j'ai vu des objets binaires avec plusieurs tailles de MB stockées dans des bases de données SQL Server. Est-ce que ce sinistre par ligne signifie vraiment une ligne de table comme dans une ligne, plusieurs colonnes?

Alors quand j'ai trois colonnes nvarchar avec chaque 4000 caractères dedans (supposons trois documents légaux écrits dans des boîtes de texte ...) - le serveur crache un avertissement?

Answer 1

Oui, vous obtiendrez un message d'avertissement sur CREATE TABLE, une erreur sur INSERT ou UPDATE

types LOB (nvarchar (max), varchar (max) et varbinary (max) permettent 2Gb-1 octets qui est comment vous stocker de grandes quantités de données et est ce que vous auriez vu.

• Pour un seul champ> 4000 caractères/8000 octets J'utilise nvarchar (max)

• Pour 3 x nvarchar (4000) dans une rangée je considérerais un de:

  • ma conception est erronée
  • nvarchar (max) pour une ou plusieurs colonnes
  • 1: 1 table enfant pour les colonnes "moins peuplées"

Answer 2

2008 traitera le trop-plein alors qu'en 2000, il refuserait simplement d'insérer un enregistrement débordant. Cependant, il est toujours préférable de concevoir dans cette optique car un nombre important d'enregistrements débordés peut entraîner des problèmes de performances lors de l'interrogation. Dans le cas que vous avez décrit, je pourrais considérer une table liée avec une colonne pour le type de document, un grand champ pour le document et une clé étrangère pour la table initiale. Si, toutefois, il n'est pas possible que les trois colonnes soient remplies dans le même enregistrement ou aux valeurs maximales, alors la conception pourrait être bonne. Vous devez connaître vos données pour déterminer lequel est le meilleur. Une autre considération est de continuer comme vous l'avez maintenant jusqu'à ce que vous ayez des problèmes et ensuite remplacer par une table de document séparée. Vous pouvez même refactoriser en renommant la table existante et en en créant une nouvelle, puis en créant une vue avec le nom de table existant qui extrait les données de la nouvelle structure. Cela pourrait empêcher beaucoup de votre code de se casser, même si vous devrez toujours ajuster les instructions d'insertion ou de mise à jour.