SQL Server 2008 : les nouveautés . . .

Bonne année...

Citation:

---

Envoyé par SQLpro

Le problème vient du fait que la plupart des développeurs sont ignare en matière de requêtes SQL !

---

Je viens de lire cette petite phrase assassine... Pas très sympa et je me permets de rebondir là dessus.

Le nombre de technologies et d'outils ne cesse de croître au point qu'il devient impossible de tout maîtriser.

En développement conventionnel,

Certains sont bons en développement, ils n'utilisent que des requêtes simples avec les bases de données et traitent les problématiques métier à l'aide de leur langage.

D'autres plus forts en base de données préfèrent implémenter leurs traitements en base et ne se contentent que de publier les résultats à l'aide de leurs écrans.

En développement de SOA,

les contraintes liées aux bonnes pratiques sont telles qu'il devient nécessaire d'être capable de faire la part des choses afin de déterminer dans quel cas il est judicieux d'effectuer un traitement en base et dans quel autre il faut l'implémenter dans une des couches objet.

A ta remarque j'ajouterais qu'il n'est pas rare par exemple de voir des "super experts" en base de données, omettre d'utiliser l'intégrité référentielle ou l'indexation, ou encore se contenter de se faire plaisir en créant des procédures stockées qui ne sont d'ailleurs pas toujours optimales au niveau des performances.

Il n'est pas possible de tout connaître aussi, c'est pourquoi des EQUIPES de développement se mettent en place. Imagine si au sein de ces équipe les développeurs commencent à dire que les DBA sont tous nuls et que les DBA font de même avec les développeurs.

A mon sens, il est bien plus utile de profiter des forces de chacun plutôt que de mettre en exergue leurs faiblesses. Les projets ne s'en porteront que mieux, l'ambiance sera plus détendue et les résultats seront meilleurs.

J'ai lu ton papier sur la médiane. Il est très bien rédigé. Tu proposes une méthode d'approche empirique pour arriver à un résultat plus ou moins optimisé. Je peux me tromper mais compte tenu des performances des primitives de traitement des ensembles des langages comme C# voir C++ (pour les cas les plus extrêmes), je ne suis pas certain que l'approche "tout en base" soit la plus pertinente. D'ailleurs, il est possible, dans les dernières versions de SQL server, de faire appel à des traitements externes pour palier aux faiblesses du SGBR.

Je pense qu'une approche concertée entre un expert en développement et un autre en base de données permettrait certainement de donner un meilleur résultat...

Bien à toi

Laurent

bonjour,

je dois avouer que je préfère écrire ( surtout pour les tables multiples ):

Code:

---

1 2	SELECT COLONNEA,COLONNEB FROM TABLE1,TABLE2 WHERE TABLE1.COLONNEA=TABLE2.COLONNEA

---

plutôt que

Code:

---

1 2	SELECT COLONNEA,COLONNEB FROM TABLE1 INNER JOIN TABLE2 ON TABLE1.COLONNEA = TABLE2.COLONNEA

---

pourtant, je crois, mais j'aimerais être certain, je crois que SQL Serveur 2008 n'acceptera plus que la deuxieme façon d'écrire plus "moderne" ( SQL 92 - SQL 2 )

J'attends Février pour commander la version francaise de sql serveur 2008, d'ici là, si quelqu'un pouvait me dire si c'est une certitude... ce serait sympa!
------------------------------------------------------------------
J'ai lu un livre de Peter Debetta sur SQL Serveur 2005 écrit en préversion et j'ai cru qu'il parlait de INNER JOIN, en fait, il ne parlait que du OUTER JOIN ancienne version qui disparait dans sql serveur 2005.

Extrait du site de SQL Pro A propos de SQL Serveur 2005.

Citation:

---

1.1 Jointure externes (norme SQL 1992)

Excellente nouvelle : les jointures externes avec une syntaxe propre à SQL server et rendant des résultats souvent faux, ne sont désormais plus accéptées nativement. Cette nouvelle ne va pas réjouir un certains nombre de développeurs et de DBA qui se la sont "coulé douce" depuis une décennie... Les jointures externe normatives sont dans la norme depuis 1992 et ont commencées à être supportées par SQL Server version 6.5. MS a mis en garde ses utilisateurs depuis la version 2000 qu'il était nécessaire d'utiliser les jointures normatives à base de LEFT, RIGHT ou FULL OUTER JOIN parce qu'elles ne seraient plus supportées dans les version futures...

Le message d'erreur est alors le suivant :

Msg 4147, Level 15, State 1, Line ...
The query uses non-ANSI outer join operators ("*=" or "=*"). To run this query without modification, please set the compatibility level for current database to 80 or lower, using stored procedure sp_dbcmptlevel. It is strongly recommended to rewrite the query using ANSI outer join operators (LEFT OUTER JOIN, RIGHT OUTER JOIN). In the future versions of SQL Server, non-ANSI join operators will not be supported even in backward-compatibility modes.

---

Encore désolé.
---------------------------------------------------------------------
Je confirme, apres test sur serveur sql serveur 2008, la requete sql 1 suivante s'execute bien :

SELECT * FROM Table1,TableA WHERE Table1.clef_primaire=tableA.clef_primaire
_____________________________________________________________

je vous renvois à une discussion particulierement interessante sur ce sujet dans le forum sql:

http://www.developpez.net/forums/sho...d.php?t=522319

Salut,

Je ne sais pas si la première notation sera interdite en tous les cas elle me rappelle de biens mauvais souvenirs alors que je travaillais dans une équipe Oracle qui travaillait comme ça. Dès que l'application a dépassé les 30 tables c'est devenu la foire d'empoigne...

Personnellement j'ai toujours utilisé la méthode "moderne", d'ailleurs ayant commencé les bases de données il y a près de 20 ans, si cette méthode est moderne, la tienne ne serait-elle pas "ancestrale" ?

Tu ne devrais pas avoir à te poser ces questions, essayes tant que possible de respecter les standards. C'est pas toujours aussi pratique que ce que l'on voudrait mais ça permet d'assurer une certaine pérennité dans le temps des applications que tu créeras.

Je ne sais pas si tu fais du web, mais si c'est le cas, tu comprends certainement la nécessité d'une telle démarche.

Bonne continuation

Laurent

Citation:

---

Je pense qu'une approche concertée entre un expert en développement et un autre en base de données permettrait certainement de donner un meilleur résultat...

---

Tout à fait d'accord avec toi... J'adore aussi les phrases assassines. Les temps sont devenus monotones : plus de guerres, plus d'émeutes ! ;-)

Reste que la grosse différence est qu'en SGBDR l'optimiseur est capable d'analyser des centaines de manières de traiter le problème et choisir la meilleurs manière de la faire au moment opportun (en fonction du volume des données et des valeurs des paramètres au moment de lancer la requête). Or cela est impossible à faire en traitement itératif ! Sauf à passer une vie d'homme à écrire chaque traitements en multipliant les algorithmes à foison.

Autement dit : s'il y a du volume à traiter le SGBDR sera très très souvent le plus rapide. La condition sinequanone est que la base doit être bien modélisée. C'est à dire sans redondance (respect des formes normales) et correspondre à l'usage que l'on en fait (ce n'est pas toujours le cas, il y a même beaucoup de BD dans lesquelles on respecte a peu près bien le premier point mais sans tenir compte du second !).

A +

Citation:

---

Envoyé par SQLpro

10) ajout du paramétrage de nom de table pour les requêtes (exemple : SELECT * FROM @MaVariableTable)

---

J'ai du mal à saisir l'interêt de ce point. Cela peut être pratique mais ça risque d'encourager les bidouilles des gens qui utilisaient pour un rien du SQL dynamique au lieu de SQL relationnel ?

edit:
Sinon ce que je retiens de positif en ce qui me concerne:

Citation:

---

Envoyé par SQLpro

1) types SQL date et time (date, time, datetime2, datetimeoffset) avec rajout de la semaine iso et gestion des fuseaux horaires
2) compression des données pour le Data Warehouse
3) ordre SQL MERGE (INSERT et UPDATE combiné)
14) Ajout du GROUPING SETS pour les fonctions OLAP des bases OLTP
17) Nombreuses avancées pour BI.

---

Citation:

---

SELECT * FROM @MaVariableTable
J'ai du mal à saisir l'interêt de ce point.

---

Bien d'accord... C'était une forte demande de la communauté. Mais les demandes sont parfois idiotes !!!

A +

Citation:

---

Envoyé par ylarvor

bonjour,

sqlserveurcentral m'a proposé l'adresse suivante, http://www.sqlserverbeta.com/Home/tabid/36/Default.aspx
je me suis inscrit et ce matin, j'ai essayé sql serveur 2008 sans téléchargement sur mon poste... cool!

bon test

---

Citation:

---

Envoyé par SQLpro

Le problème vient du fait que la plupart des dévelopeurs sont ignare en matière de requêtes SQL !

---

Je confirme.

Je ne compte plus le nombre de requêtes tordues que j'ai du réécrire afin d'optimiser les performances.

Seulement, avec le nombre de technologies qu'il faut connaître afin de développer une application, ainsi que leur évolution, la compréhension de SQL et d'un SGBD demeure le parent pauvre de la programmation.

Je pense que le problème provient souvent dans l'écriture même de la requêtes SQL.

Souvent, le développeur commence par écrire le SELECT avant d'écrire les jointures (car une requête SQL s'écrit dans cette order là).

Pour la bonne écriture d'un requête, je pratique dans l'ordre suivant :

- Identification des tables où se situent les données à récupérer
- Définition de l'arbre de jointure
- Clause WHERE
- Colonne dans le SELECT
- Tri éventuel.

C'est une manière parfaite de procéder pour la mise au point de requêtes.

je rajouterais une seule chose, commencer par un

Code:

---

1 2	SELECT TOP n * -- mes colonnes FROM ...

---

Afin de voir la bouille des résultats pendant toute la phase de mise au point de la requête.

A +

Bonsoir,

Citation:

---

Je dois avouer que je préfère écrire ( surtout pour les tables multiples ):

Code:

---

1 2	SELECT COLONNEA,COLONNEB FROM TABLE1,TABLE2 WHERE TABLE1.COLONNEA=TABLE2.COLONNEA

---

plutôt que

Code:

---

SELECT COLONNEA,COLONNEB FROM TABLE1 INNER JOIN TABLE2 ON TABLE1.COLONNEA = TABLE2.COLONNEA

---

---

Où se situe la différence, le plan de requête étant inchangé ?
Ce que je veux dire c'est : pourquoi est-il moche d'utiliser JOIN, même dans le cas où le nombre de tables sur lesquelles ont lieu les jointures est important ?

D'autre part je trouve cela plus lisible, car on "sépare" les restrictions sur les données des tables dans les quelles effectuer les recherches.

Merci de vos réponses ;)

Personnellement, je trouve plus lisible d'écrire avec INNER JOIN, car on visualise mieux l'arbre de jointure de cette manière.

Et puis, il n'y a pas que l'INNER JOIN mais aussi le LEFT JOIN que j'utilise.

Visuellement, je préfère écrire

Code:

---

1 2 3 4 5

SELECT ... FROM MaTable1 INNER JOIN MaTable2 ON Col1 = Col2 INNER JOIN ...

---

slt

Qu'en est il de Team Edition Database Professional : y a t-il de nouvelles fonctionnalités ?

Salut,

Personnellement j'ai mis au point une technique (qui a surement déjà du être faite) qui consiste à créer une table d'identification d'élément pour chaque nature d'élément. Cette table contient uniquement un Guid qui est la clef et dont la valeur par défaut est newid().

Ensuite, je crée une "sous" table qui contient vraiment les infos intéressantes qui n'a pas de clef primaire mais qui a une rowguid.

La liaison doit permettre d'avoir des enregistrements dans la table mère qui n'en ont pas dans une de ses tables filles (ça fait un lien avec une clef de chaque côté dont le "fil" est en pointillés).

Imaginons une gestion des tiers (Ma clef primaire porte le nom de ma table) voir ma charte de nommage : http://sossoa.blogspot.com/2007/12/c...de-donnes.html

Table
TIERS_MT_Tiers (les personnes)

TIERS_MT_Tiers uniqueidentifier

Table
TIERS_ST_PP (les personnes physiques)

TIERS_ST_PP uniqueidentifier

FK_UTIL_BT_Genres uniqueidentifier

txtNom nvarchar(50)

txtPrenom nvarchar(50)

Table
TIERS_ST_PM (les personnes morales)

TIERS_ST_PM uniqueidentifier

txtRaisonSociale nvarchar(50)

Enfin la table adresse qui est la même quelque soit le type de tiers et qui point sur la table mère et non sur les sous-tables filles

TIERS_ST_Adresses (les adresses postales)

TIERS_ST_Adresses uniqueidentifier

FK_TIERS_MT_Tiersuniqueidentifier

txtAdresse1 nvarchar(50)

txtAdresse2 nvarchar(50)

txtAdresse3 nvarchar(50)

txtCP nvarchar(10)

txtVille nvarchar(50)

TIERS_MT_Tiers sert un peu de table "abstraite" comme le ferait une classe abstraite. D'ailleurs, au risque de choquer ceux qui prônent le découplage Base / objets, les unes fonctionnent très bien avec les autres et ça permet même de créer entités objet à persistance quasi automatique.

Ça évite aussi d’avoir a faire des UNION qui, comme vous le savez ne sont pas hyper performants.

Quelques petites procédures stockées sont quand même à prévoir pour l'exploitation d'une telle structure.

Si quelqu'un est allé plus loin dans ce sens, j'aimerais bien partager ses expériences.

Je ne conseille pas cette structure pour de très gros projets car ça complique pas mal par contre, pour faire du dev ultra rapide en ASP.net c'est pratique.

++

Laurent

Cette table :
[QUOTEE]TIERS_ST_Adresses (les adresses postales)
TIERS_ST_Adresses uniqueidentifier
FK_TIERS_MT_Tiersuniqueidentifier
txtAdresse1 nvarchar(50)
txtAdresse2 nvarchar(50)
txtAdresse3 nvarchar(50)
txtCP nvarchar(10)
txtVille nvarchar(50)[/QUOTE]

Ne respecte pas la 1er forme normale.

Il aurait fallut faire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

TIERS_ST_Adresses (les adresses postales) TIERS_ST_Adresses uniqueidentifier FK_TIERS_MT_Tiersuniqueidentifier txtCP nvarchar(10) txtVille nvarchar(50)   TIERS_ST_AdresseLignes (les lignes d'adresses postales) TIERS_ST_AdresseLignes uniqueidentifier FK_TIERS_ST_Adresses uniqueidentifier txtAdresse nvarchar(50) intPositionLigne

---

Enfin, pour des raisons de performances, je vous déconseille totalement le type uniqueidentifier qui est long à calculer, long à stocker et par conséquent environ 8 fois plus couteux en jointure (même indexé) qu'un entier INT.

A +

Salut,

Effectivement, cette table n'est pas parfaite. C'est un exemple, 2 ces données ne sont quasiment jamais utilisées. Mais tu as raison.

L'implémentation que tu suggères ne me parait justifiée que dans le cas où il faudrait faire des recherches ou tout autre traitement sur les nom des rues ou les lignes d'adresse. Si ça n'est pas le cas, ça complique un peu pour une question de style.

C'est aussi pourquoi on différencie le MCD du MCP...

++

Laurent

Code:

---

C'est aussi pourquoi on différencie le MCD du MCP...

---

A ce niveau là, non,... C'est par contre le rôle des vues...

A +

SQL SERVER 2008 - SQL, TRANSACT SQL - CONCEPTION ET REALISATION D'UNE BASE DE DONNEES - edition ENI - Jerome Gabilleau.

Bonjour,

A propos de la 1NF.

Citation:

---

Envoyé par SQLpro

Cette table :

Code:

---

1 2 3 4 5 6 7 8

TIERS_ST_Adresses (les adresses postales) TIERS_ST_Adresses uniqueidentifier FK_TIERS_MT_Tiers uniqueidentifier txtAdresse1 nvarchar(50) txtAdresse2 nvarchar(50) txtAdresse3 nvarchar(50) txtCP nvarchar(10) txtVille nvarchar(50)

---

Ne respecte pas la 1ere forme normale.

---

Je m’inscris en faux contre cette affirmation et m’appuie pour cela sur des références incontestables et incontournables comme Codd, Date, Silberschatz et Korth, Maier, Gardarin et Cie, pour affirmer à mon tour que la table en cause respecte bien la 1re forme normale.

Je cite (et traduis) Codd qui a écrit en 1971 :

Une table est en première forme normale si aucune de ses colonnes ne peut prendre de valeur qui soit elle-même un ensemble.

Et en 1990, il apporte cette précision :

Vu du SGBD, les valeurs des domaines sur lesquels chaque relation est définie doivent être atomiques.

Ce qui veut dire que, vu du SGBD, ces valeurs ne sont pas décomposables.


A l’instar par exemple de David Maier et de quelques autres, on peut encore apporter cette précision si besoin était :

Les valeurs des domaines ne sont ni des listes, ni des ensembles.

Notez encore le "si et seulement si" de Date :

A relation R is in first normal form if and only if underlying domains contain atomic values.

Concernant la table TIERS_ST_Adresses :

Les colonnes txtAdresse1, txtAdresse2, txtAdresse3 font référence au domaine nvarchar(50) dont les valeurs sont par définition atomiques au sens SQL ; la table TIERS_ST_Adresses est donc en 1NF. Sinon, si les valeurs du domaine nvarchar(50) ne sont pas atomiques, la colonne txtAdresse de la table TIERS_ST_AdresseLignes y faisant référence elle aussi, elle viole à son tour la 1NF (et donc la 2NF, etc.)

Outre ceux que j’ai cités, ce ne sont pas non plus des ténors du Relationnel comme Ullman, Miranda, Delobel et Adiba qui me contrediront.

Et je ne suis pas du tout d'accord avec ton interprétation trop littérale.

En effet lorsque dans une table on rencontre le motif suivant :

Code:

---

1 2 3

txtAdresse1 nvarchar(50) txtAdresse2 nvarchar(50) txtAdresse3 nvarchar(50)

---

On peut se demander s'il y en aura jamais 3 et toujours 3. pourquoi pas 4 ou 2 ?
Autrement dit la seule façon dont j'accepterais que cette table ne viole pas la 1FN est que l'on me certifie que toujours pour toutes les lignes de la table alors soit ces 3 colonnes seront toutes trois valuées, soit qu'aucune d'elle ne le soit.
Or à l'évidence ce ne sera pas le cas ici...
En revanche si d'aventure nous modélisions des adresses IPV4 j'admettrais parfaitement 4 colonnes de type entier 2 octets. En effet une adresse IP a toujours tous ses attributs valuées (mais manque de pot, l'IPV6 arrive !).
Mais revenons à l'exemple de l'adresse. Ce que veulent généralement dire les gens qui font cela et qui ne vont pas jusqu'au bout de leur modélisation, c'est qu'ils voudraient en fait un tableau de lignes d'adresses comme ceci :

Code:

---

txtAdresse2 ARRAY nvarchar(50)

---

Alors par manque d'imagination ils se limitent d'eux même à une valeur arbitraire (d'ailleurs la norme de l'adresse postale va jusqu'à 5 lignes d'adresse en sus du code postal et de la ville et se limite à 38 caractères... je me tue à le dire dans mes articles, mais passons ! http://sqlpro.developpez.com/cours/normes/#L3).
Or nous savons que cela n'est pas du pur relationnel et nous connaissons les problèmes que cela pose en général d'un point de vue requête comme au sujet des performances.
Et la traduction de tableau, est, en pur relationnel, le concept de table.

CQFD

Je suis même encore plus méchant que cela, car dans les cours de modélisation que je donne, je considère comme faute le motif suivant :

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE T_CLIENT_CLI ( ... CLI_TELEPHONE_DOMICILE VARCHAR(20), CLI_TELEPHONE_BUREAU VARCHAR(20), CLI_TELEPHONE_PORTABLE VARCHAR(20), CLI_TELECOPIE_BUREAU VARCHAR(20), ... )

---

En effet cela devrait être traduit en une table de téléphones avec des types de téléphone (GSM, Fixe, FAX...) et des localisations (Domicile, bureau..)

A +

Citation:

---

Envoyé par SQLpro

je ne suis pas du tout d'accord avec ton interprétation trop littérale.

---

Je n’interprète rien du tout. Je ne fais que citer les auteurs de référence, au sujet de la définition de la 1NF, notamment le père du Modèle relationnel, qui se trouve avoir aussi inventé la 1NF (et qui du reste, n’était pas obligé de le faire : en 1969 il était muet sur le sujet (Cf. E.F. Codd - Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks. IBM Research Report RJ599 (August 19th, 1969)).

Vous avez le droit d’être en désaccord avec Codd, mais alors n’appelez pas Première Forme Normale la contrainte que vous préconisez — au demeurant tout à fait pertinente — à savoir qu’un ensemble de colonnes d’une table ne puisse constituer une liste.

Citation:

---

Envoyé par SQLpro

nous savons que cela n'est pas du pur relationnel et nous connaissons les problèmes que cela pose en général d'un point de vue requête comme au sujet des performances

---

Certes, il y a un problème relevant de la modélisation conceptuelle, mais le Modèle relationnel de données n’a rien à voir avec cela. Que les requêtes soient beaucoup plus balourdes, c’est certain, mais ça n’est pas non plus le problème du Modèle relationnel qui en l’occurrence n’a pas à se prononcer. Quant aux performances, elles sont l’affaire du SGBD car elles relèvent de la réalisation et non pas des concepts.

Citation:

---

Envoyé par SQLpro

Je suis même encore plus méchant que cela, car dans les cours de modélisation que je donne, je considère comme faute le motif suivant :

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE T_CLIENT_CLI ( ... CLI_TELEPHONE_DOMICILE VARCHAR(20), CLI_TELEPHONE_BUREAU VARCHAR(20), CLI_TELEPHONE_PORTABLE VARCHAR(20), CLI_TELECOPIE_BUREAU VARCHAR(20), ... )

---

En effet cela devrait être traduit en une table de téléphones avec des types de téléphone (GSM, Fixe, FAX...) et des localisations (Domicile, bureau..)

---

Bien entendu, cette liste de colonnes dénote une maladresse évidente dans la conception de la table et il faut renvoyer à l’école celui qui en est l’auteur. Mais je répète que, stricto sensu, ceci ne concerne pas la première forme normale.

J’ai eu, moi aussi, bien souvent à expliquer à des concepteurs peu aguerris les risques de ce genre de modélisation. Par exemple, l’un d’eux était très fier de son MCD concernant les statistiques du réseau (le produit final devait être vendu chez nos clients...) Mais une entité-type comportait une liste d’attributs, un pour chaque jour de la semaine, une deuxième liste était du même tonneau, ainsi qu’une troisième liste... Je lui ai posé la question suivante : "Que feras-tu de ton système le jour où certains de tes clients voudront des statistiques non pas sur 7 jours, mais sur 10 ou 15 jours ?", "Crois-tu que SQL est fait pour sommer un nombre fixe de colonnes ?", etc. Il a tout de suite compris l'enjeu et s’est empressé de revoir sa copie.

Je vous donne matière à être très, mais alors très méchant, concernant une table qui est en première forme normale, mais qui mérite une fort mauvaise note par ailleurs...



http://www.fsmwarden.com/developpez/...Sysindexes.jpg
Cette image date de quelques années. Pour avoir quelque chose de plus frais (mais toujours aussi mal modélisé) :

Guide to SQL: Reference, G251-2283-00