Les types système: Evolution de SQL SERVER 7.0 à SQL SERVER 2005

SQL Server 7.0 définit :
Les Numériques Exactes
Les types d’entiers
INTEGER 4 octets
SMALLINT 2 octets
TYNYINT 1 octet 0 à 255.
Les numériques exactes
DECIMAL (P, S) numérique de précision P, avec S chiffres derrière la virgule
DEC (P,S) et NUMERIQUE(P,S)
Les Numériques Approximatifs
FLOAT(n) Flottants
REAL Synonyme de FLOAT 4 octets
Les Monétaires
MONEY et SMALLMONEY
date et temps
DATETIME Date et heure 8 octets
SMALLDATETIME
Les caractères
char(n) – ANSI – 8000 caractères.
varchar(n) – ANSI – 8000 caractères.
nchar(n) – Unicode – 4000 caractères.
nvarchar(n) – Unicode – 4000 caractères.
text – ANSI – 1,073,741,824 caractères.
ntext – Unicode – 536,870,912 caractères.
Les Binaires :
Binary[n] 1 à 8000 octets et VarBinary[n]
Image : 0 à 2 Giga
spéciaux :
bit, cursor, sysname,timestamp

SQL Serveur 2005 définit 7 catégories de types:

- Numérique exact
big int, int, smallint, tinyint,
decimal(p,s), numeric(p,s)

Les types Numérique Exact permettent de spécifier la précision souhaitée pour un attribut numérique, et donc de représenter une valeur exacte. BigInt est nouveau depuis 2000

- Numérique approximatif
float, real.

Les numériques flottants correspondent aux types couramment utilisés en programmation (FLOAT, DOUBLE) et ne représentent une valeur qu?avec une précision limitée.
Par exemple, si vous stocker 1,00015454 dans un float(8), seul les 8 digits sont garantis : 1,000154. Le reste est arrondi.
On utilise ces valeurs arrondis plutôt dans des applicatifs scientifiques que financier.
- Monnaie
money,smallmoney
4 digit de précision : exemple : smallmoney 214,748.3647

- Date et Time
datetime, smalldatetime

- Caractères
char(n),nchar(n),varchar(n),varchar(max),nvarchar(n),nvarchar(max),text,ntext

char(n) – ANSI – 8000 caractères.
varchar(n) – ANSI – 8000 caractères.
varchar(max) – ANSI – 1,0773,741,824 caractères.
text – ANSI – 1,073,741,824 caractères.

nchar(n) – Unicode – 4000 caractères.
nvarchar(n) – Unicode – 4000 caractères.
nvarchar(max) – Unicode – 536,870,912 caractères.
ntext – Unicode – 536,870,912 caractères.

la différence entre char et varchar provient du stockage de la totalité des caractères pour le char contre le stockage des seuls caractères utilise pour le varchar.

- binary
binary(n),varbinary(n),varbinary(max),image

Le type Binary stocke des flux binaires, des images, des fichiers.

- caractères spéciaux ( xml, guid )
bit,timestamp,uniqueidentifier,sql_variant,cursor,table,xml

Bit : stocke 0,1 ou Null.

Timestamp : Une table ne peut posséder qu’une seule colonne Timestamp qui est mis à jour sur la date/heure de la base à chaque insertion ou mise à jour.

UniqueIdentifier: Un identifiant 16 bits qui identifie la ligne dans la base de données, l’instance ou le serveur.

SQL_variant : Nouveau depuis 2000,le type indéfini de cette colonne de 8000 caractères permet de stocker n’importe quoi.

Cursor: Utilisé par les applications qui déclarent des cursors. Ne peut être utilisé dans une table.

Table : Nouveau type depuis 2000, Utilisé dans une variable de procédure stockée, trigger ou function.

XML : Nouveau depuis 2005, il stocke un document xml de 2 gigaoctets.

Redécouvrir SQL Serveur 2005 – Nouveaux Types de Données : Varchar(max),nvarchar(max) et varbinary(max)

Sous SQL Serveur 7 et SQL Serveur 2000, une ligne de table ne peut excéder 8000
bytes.
VARBINARY ne peut exceder 8000 bytes à condition que la ligne ne contient qu’une
colonne VARBINARY.
Une colonne VARCHAR ne peut excéder 8000 caractères.
Une colonne NVARCHAR ( 2 bytes par caractère ) ne peut excéder 4000 caractères.
varchar(n)ANSI – 8000 caracteres.
nvarchar(n)Unicode – 4000 caracteres.

Pour stocker plus de données dans une seule ligne de table, vous devez utiliser
les BLOB text,ntext et image. Ces données sont stockées dans une collection de
pages séparées de la page principale qui stocke les données. Ces données BLOB
sont stockées dans une B TREE Structure. Ces données BLOB ne sont pas du tout
aisée à manipuler, d’abord, on ne peut pas stocker un BLOB dans une variable de
procédure ou de fonction et il est impossible d’utiliser des fonctions de
chaines de caractères comme REPLACE, CHARINDEX or SUBSTRING avec un BLOB. Dans
la plupart des cas, vous devez utiliser READTEXT, WRITETEXT, et UPDATETEXT avec
les BLOBs ( text,ntext et image ).
Le type text,ntext et image doivent normalement disparaitre dans SQL Serveur
2008.
textANSI – 1,073,741,824 caracteres.
ntextUnicode – 536,870,912 caracteres.

Dans SQL serveur 2005, Varchar(max),nvarchar(max) et varbinary(max) supportent 2
gigabits de données. On peut utiliser ces types dans une procédure stockée ou
une fonction comme variable et les fonctions de caractères peuvent être utiliser
avec ces types là. Une réelle avancée pour les utilisateurs.
varchar(max)ANSI – 1,0773,741,824 caracteres.
nvarchar(max)Unicode – 536,870,912 caracteres.

[SQL Serveur] Connaissez-vous le type Numeric(p,s) ?

Vous connaissez tous les types INT ou BIGINT pour stocker des entiers.

Vous connaissez le type FLOAT pour stocker des valeurs arrondis de décimaux.

Par contre le type NUMERIC(p,s) et le type DECIMAL(p,s) sont moins connus.

Ils permettent de stocker des valeurs entières ou décimales avec précision.

Ce sont les types à utiliser de préférence dans une application financière

PowerAMC les utilisent pour générer ces identity!

La première valeur p indique nombre maximal de digit qui peut être stocké. Avec une valeur maximale de 38 digits( 10^38 )

La valeur s indique le nombre de chiffres après la virgules.

Exemple: Pour stocker un entier de 0 à +/- 9999 : NUMERIC(4,0).

Exemple : Pour stocker un décimal de 0 à +/- 99,99 : DECIMAL(4,2).

Il semble que NUMERIC(p,s) et DECIMAL(p,s) soient des synonymes. Je recommande NUMERIC(p,0) pour les entiers et DECIMAL(p,s) pour les réels.

La norme SQL recommande d’ utiliser un synonyme que SQL Serveur accepte : DEC(p,s).

Le changement de version entre SQL serveur 2000 et 2005 est il nécessaire ?

En mars 2007, quand j’ai décidé de me plonger dans l’étude approfondie des bases de données pour en faire un métier, je me suis intéressé à SQL Serveur 2005 qui était le produit le plus récent. Après 2 mois d’étude du produit sur la version developper : J’écrivais cet article qui vantait les nouveautés SQL de cette version à juste titre:
Référence : ici

SQL Serveur 2005 est plus performant en terme de haute disponibilité mais SQL Serveur 2000 sait déjà faire les 3 sortes de réplications.

SQL Serveur 2005 est un trés bon produit OLAP mais SQL serveur 2000 possède déjà les lots dts et un noyau Analysis service.

D’autre part, SQL Serveur 2005 est encore mieux sécurisé en comparaison des autres sgbd du marché et il offre une scalabilité encore plus grande à la montée en charge.

Néanmoins, Aujourdhui, je travaille à mi-temps sur SQL Serveur 2000 et je trouve que ce SGBD est une trés bonne base de données suffisante pour la majorité des bases internet.

Lire la suite

[SQL Serveur] Liens concernant la migration 2000-2005.

Vidéo Microsoft sur la migration 2000-2005 :
http://www.microsoft.com/france/vision/WebcastTechNetTechDays.aspx?EID=fd12de03-6bb2-435b-a135-da0db259d8d3

Tutorial sur le conseiller de mise à niveau 2000-2005 :
http://www.asp-php.net/tutorial/sql-server/sqlupgradeadvisor.php

La migration 2000-2005 par christian Robert :
http://blogs.codes-sources.com/christian/archive/2007/03/27/sql-server-migrer-de-2000-2005-les-commandes-indispensables.aspx

Tutorial – La migration par sauvegarde-restauration 2000-2005 :
http://www.technos-sources.com/tutorial-restaurer-base-provenant-backup-moteur-sql-server-2000-37.aspx

Tutorial supinfo – La migration 2000-2005 par Copy Database :

http://www.laboratoire-microsoft.org/articles/server/migration-sql-server-2000-2005/

Pourquoi ne trie t’on jamais une vue en SQL ?

En SQL ANSI, il est connu qu’une vue ne doit jamais être trié. On n’utilise donc jamais de ORDER BY dans une vue.
J’avoue que j’ai essayé de trouver une bon raison à cela et je l’ai finalement trouvé…

Comme vous le savez, une vue n’est qu’un enregistrement de requête, elle n’a pas d’existence physique comme une table à part les vues matérialisées mais c’est un autre problème!

Imaginez le scénario suivant :

Vous créez sur sql serveur une vue avec un order by. SQL Serveur 2000 ne posera aucune question et conservera le tri en réserve comme vous le souhaitez.

CREATE VIEW MAVUE AS SELECT NOM,PRENOM FROM FAMILLE ORDER BY NOM,PRENOM;

Jérome, votre collègue de toujours à besoin de cette vue mais lui, il veut trié par PRENOM,NOM…il écrit donc sa requète :

SELECT * FROM MAVUE ORDER BY PRENOM,NOM;

Jérome a le droit d’écrire cela.

Maintenant, Qu’avez vous demander à SQL SERVEUR 2000 ?

Il doit trier par NOM,PRENOM puis par PRENOM,NOM dans la même requête, avouez que c’est fort en chocolat de demander cela.

Voilà, pour moi, la raison pratique pour laquelle on ne doit jamais écrire un order by dans une vue. Parce qu’il y a aura 10 utilisateurs différents de la vue et qu’aucun d’eux n’aura les mêmes besoins. Alors même si sql serveur 2000 autorise le order by dans une vue, ne l’utilisez jamais dans la vue mais en dehors, au plus prés du besoin!

[SGBD] [Optimisation] Pourquoi l’écriture de fonctions encapsulées est à bannir en SQL ?

Je voudrais revenir sur un article de Rudi éclairant pour moi :

http://rudi.developpez.com/sqlserver/tutoriel/optimisation/

Dans cet article, il écrit « Une erreur commune, qui peut affecter fortement les performances, est d’écrire du code SQL avec la même approche intellectuelle que pour l’écriture de code procédural. »
Lire la suite

[sql serveur] Quels sont les outils pour indexer les tables en amont, pendant la modélisation ?

Si vous possèdez Power AMC, cet article ne s’adresse pas à vous car Power AMC indexe toutes les clefs étrangères sur simple demande, par contre, si vous utilisez Toad Data Modeler 4.1, vous devez préciser pour chaque entite, la création de l’index de clef etrangère.
Sachez que vous pouvez gagner un temps précieux dans le temps d’execution de vos requêtes en indexant les clés étrangères de vos tables. c’est un travail facile, les clés étrangères sont identifiés, il suffit de créer un index sur la clé manuellement ou à l’aide d’un outil.Toutes les jointures s’en trouveront améliorées. Avant de vous cassez la tête en index recouvrant et autre analyses complexes… Pensez y! Ca a le mérite d’être simple et efficace.

Vous pouvez utiliser aussi le tuning advisor de 2005 ou l’index tuning wizard de 2000.
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/tunesql.mspx

Vous devez néanmoins mesurer à postériori, le gain de la pause de votre index, sur les différentes requêtes… En effet,Selon Yves Drothier de JDN :

« Par défaut, les clés primaires des tables disposent d’un index et il est pertinent de le conserver mais les clés secondaires posent un problème plus complexe. Parfois, selon le volume, la sollicitation de la base ou l’évolution des applications métiers, les index des clés secondaires perdent de leur attrait. Il est donc préférable de poser ses index en mesurant régulièrement l’efficacité de ses requêtes. »