[SQL2008][SQL2012] Select From With(NoLock)

**Donpi** · 09/07/2012, 13h34

Salut à tous,
comme certains le savent j'accuse de gros problèmes de performances dans mon système. Et ne trouvant pas de causes évidentes je commence à élaborer des théories de moins en moins logiques.

J'aimerais des avis sur celle qui suit :

On a une base de données SQL Server 2008 et 2012 qu'on accède via des applications windev et un accès natif.
Pour ceux à qui ça parle, nous n'avons pas d'accès direct au tables. Nous n'utilisons pratiquement que des variables de type sources de données remplies avec des résultats de requêtes SQL.

Bref, quand j'ai commencé à travailler à mon post actuel, tout les SELECT étaient suivi d'un WITH(NOLOCK) et les UPDATE d'un WITH(ROWLOCK).

A ce moment là, c'était indispensable pour que ça fonctionne. Car il n'y avait pas de Lock-Timeout du coup chaque requête sur une table lockée retournait directement une erreur sans attendre la moindre seconde.

Après un peu de recherche j'ai ajouté un lock timeout de 30 secondes ce qui fait que mes requêtes attendent 30 secondes avant de me retourner une erreur le cas échéant.

Je me demande si mes performances ridicules ne viendrais pas du fait que comme tout les select ont un With(Nolock) il n'ont pas besoin d'attendre que les ressources soient libérées et peuvent être tous traités en même temps.
Ce qui ferait saturé Sqlserveur quand trop de gens lancent des requêtes en même temps sur les mêmes ressources. Ce matin au pire moment j'avais ~200 locks sur mes tables.

Si vous avez lu jusqu'ici, encore un petit effort pour donner votre avis

**SQLpro** · 09/07/2012, 16h19

Envoyé par Donpi

Salut à tous,
comme certains le savent j'accuse de gros problèmes de performances dans mon système. Et ne trouvant pas de causes évidentes je commence à élaborer des théories de moins en moins logiques.

J'aimerais des avis sur celle qui suit :

On a une base de données SQL Server 2008 et 2012 qu'on accède via des applications windev et un accès natif.

Malheureusement Windiv est connu pour n'exploiter que très faibelement les capacité des SGBDR de type Client/serveur et cela peut être afin de tenter de "vendre" sa base de données Hyperfile dont il se vante d'être 10 fois plus rapide (que quoi ??? on sait pas)

Pour ceux à qui ça parle, nous n'avons pas d'accès direct au tables. Nous n'utilisons pratiquement que des variables de type sources de données remplies avec des résultats de requêtes SQL.

C'est bine là que le bât blesse !

Bref, quand j'ai commencé à travailler à mon post actuel, tout les SELECT étaient suivi d'un WITH(NOLOCK) et les UPDATE d'un WITH(ROWLOCK).

1) ce n'est pas parce que vous mettez de tels "hints" que SQL Server vous obéira
2) NOLOCK est très dangereux car il peut lire deux fois les mêmes lignes ou sauter des lignes

A ce moment là, c'était indispensable pour que ça fonctionne. Car il n'y avait pas de Lock-Timeout du coup chaque requête sur une table lockée retournait directement une erreur sans attendre la moindre seconde.

Après un peu de recherche j'ai ajouté un lock timeout de 30 secondes ce qui fait que mes requêtes attendent 30 secondes avant de me retourner une erreur le cas échéant.

Je me demande si mes performances ridicules ne viendrais pas du fait que comme tout les select ont un With(Nolock) il n'ont pas besoin d'attendre que les ressources soient libérées et peuvent être tous traités en même temps.
Ce qui ferait saturé Sqlserveur quand trop de gens lancent des requêtes en même temps sur les mêmes ressources. Ce matin au pire moment j'avais ~200 locks sur mes tables.

200 verrous c'est ridicule... Vous auriez parlé de 100 000 c'était déjà un peu couteux... Mais tour dépend de la granularité du verrous. Le fait d'avoir forcé un verrous de ligne est aussi stupide que de dire, pour tout transporter je vais prendre une camionnette..... Par exemple pour transporter un airbus, il vous faudra utiliser 0987654567890 camionnettes après avoir démonté pendant 45678909876 heures votre airbus. Est-ce une bonne pratique ? Non. SQL Server est auto adaptatif sur le verrouillage et lui avoir interdit est absurde...

Si vous avez lu jusqu'ici, encore un petit effort pour donner votre avis

70% des problèmes de perf viennent du modèle de données
Avec Windev, vous ne pouvez que très difficilement utiliser le meilleur du meilleur, c'est à dire les procédures stockées.

Commencez par me lire :
1) optimisation de MS SQL Server (5 chapitres) : http://sqlpro.developpez.com/optimisation/
2) table obèses et petites bases : http://blog.developpez.com/sqlpro/p1...ances-petites/
3) indexation : http://sqlpro.developpez.com/cours/quoi-indexer/

A +

**Donpi** · 10/07/2012, 07h54

Envoyé par SQLpro

70% des problèmes de perf viennent du modèle de données

J'en suis intimement persuadé, mais je peu pas débarqué et dire a mes collègues "Votre modèle de données est tout moisi." Je suis obligé d'emballer un peu et soigner un peu les différentes sensibilités. Je conçois bien que quand un gars de 60 ans vient dire "Les clé primaire ça ne sert a rien" c'est pas des gants en velours qu'il faut prendre mais plutôt des gants de chantier et commencer a abattre des mures... ou des gens...

Envoyé par SQLpro

Avec Windev, vous ne pouvez que très difficilement utiliser le meilleur du meilleur, c'est à dire les procédures stockées.

Je le sais bien. J'ai développez pendant 10 ans en Windev, donc se suis bien placé pour savoir que cette outil, en plus d'être bugé et mal fini, pousse le développeur à faire un travail cochon. On passe plus de temps a lutter contre les limites et les bugs de l'ide qu'a développer.
Mais bon en l'état changer d'outil est juste impensable.

Envoyé par SQLpro

Commencez par me lire

Déjà lu

**SQLpro** · 10/07/2012, 17h52

Conclusion :
1) j'augmente les ressources du serveur, mais solution de facilité très limitée : facteur de perf entre 1,2 et 3...
2) je remodélise la base, tout au moins les 20% des tables qui causent 80% des problèmes de perf et là je gagne entre 10 et 100000...

Il n'y a pas d'autre alternative !

Ce que vous pouvez déjà diagnostiquer c'est :
1) toutes les tables ont-elles des clefs primaires ?
2) la taille des clefs primaires des tables est-elle inférieur à 4 octets (32 bits), 8 octets (64 bits) ?
3) les tables sont-elles liées par l'intégrité référentielle ?
4) toute les tables ont-elle un index clustered ?
5) l'index clustered des tables est-il inférieur à 4 octets (32 bits), 8 octets (64 bits) ?

Ensuite viendra :
- le nombre de colonnes par table (qui doit rester en principe inférieur à 20)
- la longueur moyenne des lignes (qui doit rester en principe inférieur à 2000 octets)
...

A +

**Donpi** · 11/07/2012, 14h42

Envoyé par SQLpro

...
- le nombre de colonnes par table (qui doit rester en principe inférieur à 20)
...

Sur le principe je suis pas contre, mais pour quel raison le nombre de colonnes doit être inférieure a 20 ?

**Sergejack** · 11/07/2012, 17h19

Envoyé par Donpi

Sur le principe je suis pas contre, mais pour quel raison le nombre de colonnes doit être inférieure a 20 ?

C'est un nombre arbitraire au delà duquel SQL Pro pense qu'il y a probablement des colonnes dont la moindre fréquence d'utilisation pourrait justifier qu'elles soient mises à part (voire qu'elle soit indicatrice d'une non normalisation).

**SQLpro** · 11/07/2012, 20h32

Lorsque je fais cours dans les écoles d'ingé, comme lors de formation pro dans les institut, sur le sujet de la modélisation des données, je donne cette référence...
En général les gens sont interloqués et me demande pourquoi.
Alors je leurs fais relire la définition de, ce qu'est un attribut d'une entité :
"caractéristique propre à l'entité au regard du système à modéliser".
Après je leur demande de prendre une entité au hasard, par exemple la personne et de me fournir plus de 20 caractéristiques propres à la personne, au regard de ce que l'on doit modéliser (par exemple un employé, un client, un comédien..)
Si vous arrivez à m'en trouver plus de 20, je vous offre le champagne !!!

ATTENTION : un n° de téléphone, une adresse, un mail, n'est pas une caractéristique d'une personne. Une caractéristique propre doit impérativement être toujours valuable... et concerner strictement l'objet

A +

**Donpi** · 12/07/2012, 07h39

Je ne suis pas sur de comprendre...

On a une personne avec au maximum 20 caractéristiques dont l’adresse et le N° de téléphone ne font pas parti.
Cela veut dire que les données sont dans une autre table avec une liaison de type 1 1?

**SQLpro** · 12/07/2012, 09h07

Envoyé par Donpi

Je ne suis pas sur de comprendre...

On a une personne avec au maximum 20 caractéristiques dont l’adresse et le N° de téléphone ne font pas parti.
Cela veut dire que les données sont dans une autre table avec une liaison de type 1 1?

Un téléphone n'est pas une caractéristique d'une personne.
1) cette information peut concerner une entreprise, une association, une collectivité...
2) aucune personne physique ne nait avec un n° de téléphone !
3) une personne peut passer une vie entière sans avoir le téléphone !
Même chose pour adresse...

Voici un exemple de modèle adéquat :
Personnes : http://blog.developpez.com/exercices...-de-personnes/
Adresses : http://blog.developpez.com/exercices...d-une-adresse/

Et pas une association 1:1, mais 1:n, car une personne peut avoir plusieurs téléphone, plusieurs adresses en parallèle (domicile, pied à terre, résidence secondaire) ou successivement...

A +

**fsmrel** · 13/07/2012, 04h18

Bonsoir,

Envoyé par SQLpro

Un téléphone n'est pas une caractéristique d'une personne.
1) cette information peut concerner une entreprise, une association, une collectivité...
2) aucune personne physique ne nait avec un n° de téléphone !
3) une personne peut passer une vie entière sans avoir le téléphone !

Quand vous dites qu’aucune personne ne naît avec un numéro de téléphone et que celui-ci ne caractérise donc pas une personne, on a l’impression que vous sous-entendez qu’en conséquence le numéro de téléphone doit faire l’objet d’un type d’entité à part (disons TELEPHONE, en relation avec le type d’entité PERSONNE). Si tel est le cas, puisqu’une personne ne vient pas non plus au monde avec un numéro de sécurité sociale, alors ce numéro ne peut pas non plus être une caractéristique de la personne et doit donc à son tour faire l’objet d’un type d’entité ad-hoc.

Par ailleurs, il ne faut pas confondre naître à la vie et naître dans un SI (système d’information), on doit se référer à l’univers du discours auquel on se frotte. En ce qui concerne le SI de l’entreprise, si la MOE (maîtrise d’œuvre) a décidé qu’un seul numéro de téléphone était nécessaire et suffisant pour une personne (règle consignée dans le dossier de conception), il est sûr que lors des séances de validation du dossier je ferai une observation à ce sujet, mais je me plierai à la décision finale de la MOE. En conséquence, si une personne doit nécessairement naître dans le SI avec exactement un numéro de téléphone (c'est-à-dire au moins un et au plus un), je n’ai pas de raison de considérer cette donnée comme n’étant pas une caractéristique de la personne et la dégager dans un type d’entité ad-hoc (TELEPHONE) : en tant que propriété naturelle, descriptive, elle fera partie de l’en-tête du type d’entité PERSONNE. Bien entendu, ces remarques valent aussi pour le numéro de sécurité social.

De même, qu’est-ce qu’une personne (physique) du point de vue d’un SI et d’un point de vue hors SI ? Une personne peut avoir des parents, des grands-parents, des frères et sœurs, un conjoint, des enfants (on peut retrouver tout cela logé dans les fichiers, par exemple, d'un notaire), mais si cela ne concerne pas le SI, le dossier de conception sera bien entendu parfaitement muet à leur sujet. D’un autre côté, si selon le dossier de conception on a besoin de conserver des caractéristiques physiques (couleur des yeux, etc.) ou autres d’une personne, du point de vue du SI il s’agit bien de propriétés naturelles et ce sont seulement les contraintes consignées dans le dossier de conception (unicité/multiplicité, présence obligatoire/facultative) qui dicteront mon choix quant à la mise en œuvre d’un type d’entité ad-hoc (ou plusieurs).

**zinzineti** · 13/07/2012, 21h11

Envoyé par SQLpro

Après je leur demande de prendre une entité au hasard, par exemple la personne et de me fournir plus de 20 caractéristiques propres à la personne, au regard de ce que l'on doit modéliser (par exemple un employé, un client, un comédien..)
Si vous arrivez à m'en trouver plus de 20, je vous offre le champagne !!!

Supposons que l'entité PERSONNE va servir à renseigner la base de donnée d'un ethnologue ou d'un anthropologue :

cheveux,
crane,
oreilles,
front,
visage (forme du visage)
yeux,
dents,
lèvres,
menton,
coup,
épaule,
poitrine,
bras,
mains,
basin (hanche),
ventre,
fesse,
sexe,
jambe,
pied,
taille,
poids,
peau (couleur,type,...),
pilosité,
emprunte digitale,
allure (tonique, relachée, ...),
date de naissance,
lieu de naissance,
signe(s) particulier(s),
........

**dodidam** · 13/07/2012, 22h28

Bonsoir,

Envoyé par zinzineti

Supposons que l'entité PERSONNE va servir à renseigner la base de donnée d'un ethnologue ou d'un anthropologue :

cheveux,
crane,
oreilles,
front,
visage (forme du visage)
yeux,
dents,
lèvres,
menton,
coup,
épaule,
poitrine,
bras,
mains,
basin (hanche),
ventre,
fesse,
sexe,
jambe,
pied,
taille,
poids,
peau (couleur,type,...),
pilosité,
emprunte digitale,
allure (tonique, relachée, ...),
date de naissance,
lieu de naissance,
signe(s) particulier(s),
........

il me semble ici que vous ne donnez pas assez de détails, effectivement, qu'entendez-vous par cheveux ou menton ?

Dès lors, si l'on souhaite avoir des caractéristiques sur chacun des éléments comme le menton ou encore les cheveux, il conviendrait de sortir ces attributs (menton, cheveux) pour les placer dans une table, nous pourrions ainsi avoir une table menton permettant de décrire le menton (forme, taille) ou encore une table cheveux (couleur, forme...).

Envoyé par fsmrel

Par ailleurs, il ne faut pas confondre naître à la vie et naître dans un SI (système d’information), on doit se référer à l’univers du discours auquel on se frotte. En ce qui concerne le SI de l’entreprise, si la MOE (maîtrise d’œuvre) a décidé qu’un seul numéro de téléphone était nécessaire et suffisant pour une personne (règle consignée dans le dossier de conception), il est sûr que lors des séances de validation du dossier je ferai une observation à ce sujet, mais je me plierai à la décision finale de la MOE. En conséquence, si une personne doit nécessairement naître dans le SI avec exactement un numéro de téléphone (c'est-à-dire au moins un et au plus un), je n’ai pas de raison de considérer cette donnée comme n’étant pas une caractéristique de la personne et la dégager dans un type d’entité ad-hoc (TELEPHONE) : en tant que propriété naturelle, descriptive, elle fera partie de l’en-tête du type d’entité PERSONNE. Bien entendu, ces remarques valent aussi pour le numéro de sécurité social.

Il me semble que vous puissiez être amené à en faire un type d'entité (TELEPHONE), effectivement, une personne peut ne pas avoir de téléphone, dès lors, nous pourrions être amené à voir apparaître le marqueur NULL (Le bonhomme NULL) et vous précisez dans vos posts précédents,
que vous essayez toujours de modéliser de telle manière à ne pas faire apparaître le marqueur NULL (possible mise en échec de l'optimiseur ?).

Gestion des NULL

Modélisation et décomposition

En espérant ne pas me tromper.

**fsmrel** · 14/07/2012, 02h45

Bonsoir,

Envoyé par dodidam

En espérant ne pas me tromper

Hélas ! Il faudrait que vous relisiez attentivement les citations que vous faites de ce que j’écris. Je répète qu’un dossier de conception fait l’objet d’une validation sur laquelle à un moment donné s’engagent toutes les parties prenantes de l’entreprise : la MOE, les concepteurs, l’équipe du projet, l’équipe Qualité, les DBA, etc. (le champagne offert par la MOE, c’est après). Si donc il est gravé dans le marbre — cochon qui s’en dédit — qu’une personne a exactement un numéro de téléphone, je répète que celui-ci fait l’objet d’une propriété du type d’entité PERSONNE, propriété rendue obligatoire au stade de la modélisation :

MCD

DDL D

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
VAR PERSONNE BASE RELATION 
{
        PersonneId            PersonneId
      , PersonneNom           CHAR 
      , PersonneNoSecu        NIR       
      , PersonneTelefon       NoTel
      , ...
}
      KEY {PersonneId}
      KEY {PersonneNoSecu}
;

DDL SQL

Il s’ensuit que, conformément au dossier de conception et au Modèle Relationnel de Données, NULL est interdit de séjour :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TABLE PERSONNE
(
        PersonneId            INT            NOT NULL
      , PersonneNom           VARCHAR(64)    NOT NULL
      , PersonneNoSecu        CHAR(13)       NOT NULL
      , PersonneTelefon       VARCHAR(24)    NOT NULL
      , ...
    , CONSTRAINT PERSONNE_PK PRIMARY KEY (PersonneId)
    , CONSTRAINT PERSONNE_UK UNIQUE (PersonneNoSecu)
) ;

Suis-je assez clair ?

**SQLpro** · 14/07/2012, 09h12

Envoyé par dodidam

Bonsoir,

[...]

il me semble ici que vous ne donnez pas assez de détails, effectivement, qu'entendez-vous par cheveux ou menton ?

Dès lors, si l'on souhaite avoir des caractéristiques sur chacun des éléments comme le menton ou encore les cheveux, il conviendrait de sortir ces attributs (menton, cheveux) pour les placer dans une table, nous pourrions ainsi avoir une table menton permettant de décrire le menton (forme, taille) ou encore une table cheveux (couleur, forme...).

Il est rare que j’attribue des points... Vous avez parfaitement bien vu la chose !

Il me semble que vous puissiez être amené à en faire un type d'entité (TELEPHONE), effectivement, une personne peut ne pas avoir de téléphone, dès lors, nous pourrions être amené à voir apparaître le marqueur NULL (Le bonhomme NULL) et vous précisez dans vos posts précédents,
que vous essayez toujours de modéliser de telle manière à ne pas faire apparaître le marqueur NULL (possible mise en échec de l'optimiseur ?).

Gestion des NULL

Modélisation et décomposition

En espérant ne pas me tromper.

Non, vous ne vous trompez pas, mais fmsrel disait bien, et il a parfaitement raison, que le n° de téléphone était unique et connu dès la saisie !!!

Personnellement dans un tel cas, je ne me fierais pas au cahier des charges... Ou alors je me blinderais en faisant contre valider que jamais la base ne pourra évoluer en ayant plus d'un n° de téléphone..

A +

**dodidam** · 14/07/2012, 11h46

Envoyé par fsmrel

(c'est-à-dire au moins un et au plus un).

Oui, vous avez été clair. De plus, j'aurais voulu savoir quelles conséquences avez-vous pu observer de l'utilisation du marqueur NULL au sein des bases de données ?

SQLPro, fsmrel, merci pour vos commentaires.

**fsmrel** · 15/07/2012, 13h37

Bonjour,

Envoyé par SQLpro

Personnellement dans un tel cas, je ne me fierais pas au cahier des charges...

Bien sûr, c'est le moins que nous puissions faire en découvrant un projet, et ça n’est pas pour rien que j’avais écrit :

il est sûr que lors des séances de validation du dossier je ferai une observation à ce sujet

Mais je ne pensais pas qu’il eut fallu mettre les points sur les i.

Cela dit, j’en ai fait rectifier, compléter bien des dossiers de conception détaillée à l’occasion des travaux de validation ! Néanmoins, comme je l’ai écrit, une fois les règles de gestion gravées dans le marbre et que je les ai acceptées, je n’ai plus à les contester, même si je sais ce qu’il en est de la pérennité des règles d’une façon générale. Si plus tard la MOE revient sur certaines d’entre elles, et écrit par exemple qu’une personne pourra désormais avoir plusieurs numéros de téléphone, alors on repassera par les phases de validation de la nouvelle version du dossier de conception, avec à la clé la quantification de la charge de travail que cela représente pour passer à la version n+1 (développement, impact sur la production, etc.) et la détermination du coût financier qui en découle. Aléas que vivent les projets dans leur immense majorité.

Mais en revanche, si avant que les règles ne soient gravées dans le marbre je débarque dans le projet et me rends compte qu’elles ne tiennent pas la route, il est de mon devoir d’alerter la MOE, lui montrer le cas échéant qu’en l’état le projet avortera avant même sa mise en production. Si la MOE se rend à mes raisons (du reste, que peut-elle faire d’autre ?), que les développements aient commencé ou non, les conséquences seront lourdes, ne serait-ce qu’il faudra — conséquence du retard inéluctable —, par exemple trouver de nouvelles affectations pour les développeurs quand ceux-ci ont déjà reçu leur feuille de route. J’ai eu à provoquer ce genre de situation déclenchant un branle-bas de combat général, avec tout le monde sur le pont, chefs de projets, utilisateurs et Cie, afin d’arriver à accoucher de règles cette fois-ci correctes, non ambiguës, complètes, non contradictoires et tout ça, mais avec au bout du compte une application enfin opérationnelle, valide et évolutive.

Et je ne vous parle pas des situations dans lesquelles on me demande d’intervenir quand la mise en production a eu lieu, mais, Sahib, ceci est une autre histoire...

**zinzineti** · 16/07/2012, 13h22

Envoyé par fsmrel

Mais en revanche, si avant que les règles ne soient gravées dans le marbre je débarque dans le projet et me rends compte qu’elles ne tiennent pas la route, il est de mon devoir d’alerter la MOE, lui montrer le cas échéant qu’en l’état le projet avortera avant même sa mise en production. Si la MOE se rend à mes raisons (du reste, que peut-elle faire d’autre ?), que les développements aient commencé ou non, les conséquences seront lourdes, ne serait-ce qu’il faudra — conséquence du retard inéluctable —, par exemple trouver de nouvelles affectations pour les développeurs quand ceux-ci ont déjà reçu leur feuille de route. J’ai eu à provoquer ce genre de situation déclenchant un branle-bas de combat général, avec tout le monde sur le pont, chefs de projets, utilisateurs et Cie, afin d’arriver à accoucher de règles cette fois-ci correctes, non ambiguës, complètes, non contradictoires et tout ça, mais avec au bout du compte une application enfin opérationnelle, valide et évolutive.

Et je ne vous parle pas des situations dans lesquelles on me demande d’intervenir quand la mise en production a eu lieu, mais, Sahib, ceci est une autre histoire...

Bonjour François,
Je ne sais pas si tu l'envisages, mais je pense que si tu écrivais un livre sur ces expériences projets ça peut éclairer pas mal de gens, moi le premier

. Mon constat est qu'il manque sur le marché, des livres (en français) orientés SGBDs basés sur des expériences projets concrets. Il existe pas mal de bouquins (en français) scolaire, classique sur les SGBDs. Mais je retrouve rarement dans ces bouquins : les vécus personnels des auteurs, des anecdotes personnelles basées sur des expériences projets réels, bref la touche personnelle manque, l'histoire personnelle manque...et on reste souvent dans des généralités... c'est pourquoi je pense qu'un livre (qui peut être sous forme de roman...) où on peut retrouver, les anecdotes, les situations de crises, les points d’achoppements, les dénouements, bref une façon de nous faire profiter de tes nombreuses et enrichissantes expériences projets

bien sûr avec un focus sur les SGBDs. Peu importe l'éditeur du SGBD .... Qu'est ce que tu en penses ?
PS : Je pensais t'envoyer ce message en MP, mais bon je me suis dit que peut être il peut y avoir d'autres avis

**SQLpro** · 16/07/2012, 18h24

J'ai commencé cela avec la seconde édition du livre de Christian Soutou :
UML pour les bases de données
ou le théoricien (Soutou) est commenté par le praticien (brouard)

http://www.amazon.fr/ULM-pour-bases-...6&sr=1-3-fkmr1

A +

**zinzineti** · 16/07/2012, 23h25

Envoyé par SQLpro

J'ai commencé cela avec la seconde édition du livre de Christian Soutou :
UML pour les bases de données
ou le théoricien (Soutou) est commenté par le praticien (brouard)

http://www.amazon.fr/ULM-pour-bases-...6&sr=1-3-fkmr1
A +

Bien ! ça c'est une bonne nouvelle

J'ai acheté le dernier de Christian Soutou "SQL pour Oracle" (5è edition) sorti en août 2011. C'est un bon bouquin d'initiation à SQL pour oracle.
J'ai aussi ton dernier bouquin "SQL" (3è édition) édité par Synthex. Ce livre est également un livre d'initiation à SQL mais à SQL normé (1999,2003,2008) et c'est là à mon avis le point fort de ce livre : présenté le SQL standard. Si mes souvenirs sont bons je pense que je t'avais faire part de mes remarques sur ce livre...

J'attends donc avec impatience la sortie du livre sur la modélisation que tu annonces

J'espère que ne sera pas un livre d'initiation à SQL ! Du courage