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.

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.

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).

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.

Pourquoi utiliser SQL Serveur 2000 ?

D’abord pour un développement internet classique, les fonctionnalités de SQL Serveur 2000 sont largement suffisantes, la preuve, j’ai développé une base de taille moyenne avec 2005, en dev, et j’ai appliqué le script sur 2000, en prod.

SQL Serveur 2000 possède déjà les BIGINT contrairement à SQL Serveur 7. Quand on ne sait pas prédire l’avenir d’une base et que l’on voit grand pour ses clés primaires autoincrémentées. Le BigInt offre une étendue sécurisante.

Les outils d’administration de SQL Serveur 2000 sont trés élaborés:
– Le Tuning wizard
– Le Best Practice Analyser
– Le Profiler.
– Plan de maintenance.

En conclusion, on peux légitimement se poser la question de l’intérêt d’upgrader son serveur SQL, d’ajouter des fonctionnalités, pour des bases internet courante de 1 giga seulement. Néanmoins, la compétition qui a lieu dans le domaine des systèmes d’exploitation entraine une remise à jour des logiciels de back-office. Ainsi, SQL Serveur 2000 ne sera plus compatible avec les dernières versions de windows. L’industrie du logiciel est donc entrainée dans un changement permanent de produits.

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/

lien msdn : http://msdn2.microsoft.com/en-us/library/ms188037.aspx

Exemple : le problème N°6 de sqlpro ( concours developpez.com )

Pour cet exercice, il s’agit d’alimenter les nombres de 0 à 9999 dans une table de nom T_ENTIER_ENT contenant un seul champ de type entier et de nom ENT_N. Au départ, cette table contient les nombres de 0 à 9.
J’ai intitulé ce problème, ‘énumération’…

La table T_ENTIER_NET est ainsi constituée :

CREATE TABLE T_ENTIER_ENT
(ENT_N INTEGER);

INSERT INTO T_ENTIER_ENT VALUES (0) ;
INSERT INTO T_ENTIER_ENT VALUES (1) ;
INSERT INTO T_ENTIER_ENT VALUES (2) ;
INSERT INTO T_ENTIER_ENT VALUES (3) ;
INSERT INTO T_ENTIER_ENT VALUES (4) ;
INSERT INTO T_ENTIER_ENT VALUES (5) ;
INSERT INTO T_ENTIER_ENT VALUES (6) ;
INSERT INTO T_ENTIER_ENT VALUES (7) ;
INSERT INTO T_ENTIER_ENT VALUES (8) ;
INSERT INTO T_ENTIER_ENT VALUES (9) ;

ENT_N
——
0
1
2
3
4
5
6
7
8
9

Sauriez vous faire une telle requête avec un seul update ?

Voici un extrait de la table des données à insérer :

NOMBRE
———–
10
11
12
13
14
…
9995
9996
9997
9998
9999

Ma réponse :

INSERT INTO T_ENTIER_ENT(ENT_N) SELECT MAX(ENT_N)+1 FROM T_ENTIER_ENT;
go 9991

prodigieux, non ?

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!

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. »

Dans mon entreprise, nous avons une base qui a été conçu sur ce principe de l’encapsulation. Les requêtes de cette base, assez complexes, ont été rendu lisibles par l’application des principes du développement procédurale : « découpe et place dans des blocs plus petits ».

Cette base utilise donc de nombreuses fonctions tables. des fonctions. des fonctions à l’intérieur de fonctions tables. des fonctions tables à l’intérieur de fonctions tables…

Le résultat est lisible mais contre-performant comme l’explique rudi dans la partie II-D-1.

Par conséquent, si vous avez en charge le développement de requêtes, de procédures stockées : Oubliez ce que vous avez appris comme bon développeur, ne réutilisez pas, n’encapsulez pas, soyez économe avec les fonctions T-SQL.

Pour obtenir une requête rapide, vous devez écrire une requête littérale! d’un bloc! Pour rendre lisible, indentez! Organisez les jointures mais n’encapsulez pas! Ne factorisez pas en SQL !

Bon coding!

Pour trouver des repères pour l’optimisation de la requête, on doit alors prendre des données fixes comme le nombres d’accès en lecture physique, logique…

Je vous rappelle que ce qui est le plus consommateur en temps dans une requête, ce sont les accès physiques au disque.

Si on réduit le nombre d’accès, on réduit proportionnellement la durée de la requête quelque soit la charge du serveur.

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. »