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

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 :ccool:

Citation:

---

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)

Citation:

---

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 !

Citation:

---

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

Citation:

---

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

Citation:

---

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

---

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 +

Citation:

---

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

Citation:

---

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.

Citation:

---

Envoyé par SQLpro

Commencez par me lire

---

Déjà lu ;)

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 +

Citation:

---

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 ?

Citation:

---

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

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 +

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?

Citation:

---

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 +

Bonsoir,

Citation:

---

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

Citation:

---

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 :

1. cheveux,
2. crane,
3. oreilles,
4. front,
5. visage (forme du visage)
6. yeux,
7. dents,
8. lèvres,
9. menton,
10. coup,
11. épaule,
12. poitrine,
13. bras,
14. mains,
15. basin (hanche),
16. ventre,
17. fesse,
18. sexe,
19. jambe,
20. pied,
21. taille,
22. poids,
23. peau (couleur,type,...),
24. pilosité,
25. emprunte digitale,
26. allure (tonique, relachée, ...),
27. date de naissance,
28. lieu de naissance,
29. signe(s) particulier(s),
    ........

Bonsoir,

Citation:

---

Envoyé par zinzineti

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

1. cheveux,
2. crane,
3. oreilles,
4. front,
5. visage (forme du visage)
6. yeux,
7. dents,
8. lèvres,
9. menton,
10. coup,
11. épaule,
12. poitrine,
13. bras,
14. mains,
15. basin (hanche),
16. ventre,
17. fesse,
18. sexe,
19. jambe,
20. pied,
21. taille,
22. poids,
23. peau (couleur,type,...),
24. pilosité,
25. emprunte digitale,
26. allure (tonique, relachée, ...),
27. date de naissance,
28. lieu de naissance,
29. 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...).

Citation:

---

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.

Bonsoir,

Citation:

---

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

http://www.fsmwarden.com/developpez_...proprietes.png


DDL D

Code:

---

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:

---

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 ?

Citation:

---

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 !

Citation:

---

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 +

Citation:

---

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.

Bonjour,

Citation:

---

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

Citation:

---

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

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 +

Citation:

---

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

les deux livres sont sortit :
uml ed. 2
sql ed 4

A +

Bonsoir,

Citation:

---

Envoyé par dodidam

j'aurais voulu savoir quelles conséquences avez-vous pu observer de l'utilisation du marqueur NULL au sein des bases de données ?

---

Dans les applications archi testées je n’ai pas observé de bugs flagrants produits par les SGBD que j’ai secoués. Cela dit, je modélise de telle sorte que chaque colonne de chaque table de chaque base de données soit accompagnée de la clause NOT NULL. Mais je n’ai pas accès aux « relations » intermédiaires créées sous le capot à partir d’une requête puisque le SGBD ne montre pas la structure de leur en-tête et je croise les doigts avant de valider la relation finale fournie en résultat. Ces « relations » intermédiaires doivent être de même nature que celles dont elles sont issues, leurs parents — sinon elles relèveraient de la tératologie —, on appelle cela le principe de fermeture, mais je ne suis pas bien sûr que les fabricants de SGBD aient clairement cela en tête.

Si vous vous reportez ici (après la photo de Naf-Naf) aux paragraphes traitant des tables de vérité en logique trivaluée (celle de SQL) relatives au conditionnel SI p ALORS q, (qui se ramène à (NON p) OU q) et au biconditionnel p SI ET SEULEMENT SI q, on voit que l’optimiseur du SGBD peut fournir des résultats faux. Pour approfondir, je vous renvoie aux ouvrages de Date et Darwen, par exemple Date on Database: Writings 2000-2006, au chapitre 18 « Why three - And four-valued logic don’t work ».

Je rappelle en passant que le théorème de Heath ne vaut plus quand NULL est présent, alors que ce théorème est au cœur de la décomposition des schémas de relation : la décomposition d’une relation n’est plus sans perte.

Je rappelle aussi que les colonnes appartenant au schéma d’une table permettent de construire le prédicat de cette table. Ainsi, à partir de l’instruction :

Code:

---

1 2 3 4 5 6 7 8

CREATE TABLE PERSONNE ( PsnId INT NOT NULL , PsnNom VARCHAR(48) NOT NULL , PsnTel VARCHAR(24) NOT NULL , CONSTRAINT PSN_PK PRIMARY KEY (PsnId) ) ;

---

On déduit le prédicat à trois places (paramètres) :

La personne PsnId a pour nom PsnNom et pour téléphone PsnTel.

Mais qu’advient-il si la colonne PsnTel de la table PERSONNE peut être marquée NULL ? On a affaire à un autre prédicat, à seulement deux places cette fois-ci :

La personne PsnId a pour nom PsnNom, elle a peut-être le téléphone, mais nous ne savons rien à ce sujet.

Or le prédicat d’une variable relationnelle (relvar, informellement table) ne peut être à la fois à deux et à trois places (sauf à l’asile de fous ou dans un monde quantique). En vertu de quoi, la table PERSONNE est à décomposer :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

CREATE TABLE PERSONNE ( PsnId INT NOT NULL , PsnNom VARCHAR(48) NOT NULL , CONSTRAINT PSN_PK PRIMARY KEY (PsnId) ) ; CREATE TABLE TELEPHONE ( PsnId INT NOT NULL , PsnTel VARCHAR(24) NOT NULL , CONSTRAINT PSN_PK PRIMARY KEY (PsnId) ) ;

---

D’où le prédicat relatif à la table PERSONNE :

(P1) La personne PsnId a pour nom PsnNom.

Et le prédicat relatif à la table TELEPHONE :

(P2) La personne PsnId a pour téléphone PsnTel.

Sinon, je retiens que NULL est collant, tel un bout de scotch au bout du doigt et dont on n’arrive pas à se débarrasser : on est obligé d’utiliser des fonctions ad-hoc pour bricoler et éviter les pièges : COALESCE, NULLIF, IS NULL, ...

Revoyez la discussion à propos de « Sum(X+Y) = Sum(X) + Sum(Y) ? ».
Un sympathique point d’orgue offert ici par J1 est édifiant et significatif, car on y voit que NULL ça peut être de la dynamite à ne pas confier à des mains inexpérimentées.

Ceux qui font la norme SQL (voyez ici) arrivent à se vautrer lamentablement en établissant une équivalence entre la valeur de vérité UNKNOWN et NULL qui n’est pas une valeur ! Au royaume des NULL...

Bref, à la manière de Fernand Naudin (in Les tontons flingueurs), je dirais que le bonhomme NULL me les brise menu...

Bonjour,


Que CinePhil me pardonne, j’ai omis de remonter d’un cran, c'est-à-dire traduire la possession facultative d'un téléphone sous la forme d’une règle de gestion gravée dans le marbre du dossier de conception :

(RG314) Une personne est en possession d’au plus un téléphone et un téléphone est la possession exclusive d’exactement une personne :

[PERSONNE ]--0,1----(POSSEDER)----(1,1)--[TELEPHONE]

D’où la traduction en SQL :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

CREATE TABLE PERSONNE ( PsnId INT NOT NULL , PsnNom VARCHAR(48) NOT NULL , CONSTRAINT PSN_PK PRIMARY KEY (PsnId) ) ; CREATE TABLE TELEPHONE ( PsnId INT NOT NULL , PsnTel VARCHAR(24) NOT NULL , CONSTRAINT PSN_PK PRIMARY KEY (PsnId) , CONSTRAINT TEL_PSN_FK FOREIGN KEY (PsnId) REFERENCES PERSONNE (PsnId) ON DELETE CASCADE ) ;

---

Noter la contrainte référentielle TEL_PSN_FK et, en particulier la présence de l’action compensatoire CASCADE : un téléphone ne peut pas s’opposer à la suppression de son propriétaire et disparaît donc avec celui-ci (conséquence de la possession exclusive). Le dossier de conception doit tenir compte de cette situation, c'est-à-dire ne pas se limiter à l’anatomie et prendre en compte un minimum de métabolisme des données, d’où l’aménagement de la règle de gestion :

(RG314) Une personne est en possession d’au plus un téléphone et un téléphone est la possession exclusive d’exactement une personne ; la suppression d’une personne entraîne celle de son téléphone.

Bonsoir,

Merci beaucoup pour ces explications.

Citation:

---

Envoyé par SQLpro

(...)
2) NOLOCK est très dangereux car il peut lire deux fois les mêmes lignes ou sauter des lignes200 verrous c'est ridicule (...)

---

Bonjour,

Ok la dessus mais bon apres la dangerosite depend de l'application qui attends les donnees. Certaines applications prefereront un temps de reponse plus cours avec des donnees moins fiable... Ce qui est le cas avec l'erp sur lequel je travaille...

Citation:

---

Envoyé par fsmrel

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.

---

J'ai inscrit ma fille sur ma carte Vital lorsqu'elle avait 2 jours.
Elle a un numéro de sécurité sociale depuis ce jour.

Donc certes, elle est pas née avec une carte Vital dans les fesses, mais presque...

Ensuite, je pense que vous cherchez la petite bête.
Rien que dans la carte SIM d'un téléphone, où 100% des contacts on un numéro de téléphone, on se rend compte que :
- Un même contact peut avoir plusieurs numéros de téléphone, et on a donc des doublons "Estelle M", "Olivier P", "Olivier T"... et c'est tout de suite hyper pratique pour savoir si "M" ça veut dire "Maison", "Mobile", "Mari"
- Plusieurs contacts peuvent avoir le même numéro de téléphone, et on a donc des doublons "Estelle" et "Ludovic" on le même numéro, et vu qu'on est faignant, on n'en a enregistré qu'un, et on se demande à chaque fois si c'est Estelle ou Ludovic qui est enregistré...

Donc un numéro de téléphone est bel et bien totalement indépendant de l'entité "personne", quelle que soit le besoin fonctionnel.
Même pour une base d'abonnements de téléphone, on peut avoir plusieurs numéros de lignes attribuées à un même client.

Citation:

---

Envoyé par StringBuilder

Donc un numéro de téléphone est bel et bien totalement indépendant de l'entité "personne", quelle que soit le besoin fonctionnel.

---

Sophisme. Relisez ce que j’ai écrit. Essayez de comprendre qu’il n’y a pas d’absolu en matière de modélisation. Tout dépend de l’univers du discours, c'est-à-dire du SI (système d’information) que l’on modélise. Par exemple, du temps où j'intervenais chez certains opérateurs téléphoniques, un téléphone ne correspondait effectivement pas à une simple information, il était élevé au rang d'entité-type forte, en relation avec un abonné (c'est-à-dire pas totalement indépendant contrairement à ce que vous écrivez).

Par contre, chez telle association où je suis adhérent, on ne s'occupe pas de téléphones, mais d'adhérents que l'on conseille.
En même temps que le nouvel adhérent, son numéro de téléphone naît avec lui dans le système, et quand un adhérent est supprimé, par voie de conséquence son numéro de téléphone disparaît aussi (ou ses numéros s’il en a plusieurs) : dans ce contexte (cet univers), un numéro de téléphone n’est jamais qu’une propriété (mono ou multivaluée) de l’entité-type Adhérent, au même titre qu'une ligne de facture est une propriété de la facture.

Il en va des téléphones comme des prénoms : pour tel SI, le nom et le prénom des personnes sont des propriétés de l’entité-type Personne, pour tel autre SI ça n’est pas le cas. J’ai par exemple souvenir d’une entreprise de vente par correspondance pour laquelle le prénom des clientes était une entité-type très importante (univers du discours oblige) et le DSI serait monté sur ses grands chevaux si j’avais ravalé le prénom au rang de propriété de la cliente. Toute la nuit les imprimantes crachaient du courrier du genre : « Chère Monique, c’est votre fête et c’est avec plaisir que je vous fais parvenir ce petit cadeau... » ; c’était dans les années soixante-dix et depuis le système a sans doute été bien aménagé du fait des (r)évolutions technologiques, mais sur le fond le principe a dû rester le même.

Citation:

---

Envoyé par StringBuilder

J'ai inscrit ma fille sur ma carte Vital lorsqu'elle avait 2 jours.
Elle a un numéro de sécurité sociale depuis ce jour.

---

Non elle a un numero INSEE depuis sa naissance. Elle a par contre le meme numero de secu social que le tien tant qu'elle t'es rattache a moins que la loi est change dernierement...

Sur mon attestation de droits, elle apparaît bien comme ayant un code SECU.

La gestion des numéros de SECU a évolué. Il y a quelques années, un enfant avait le numéro de SECU de son père jusqu'à ses 15 ou 16 ans (date à laquelle il a son propre dossier à la SECU).

Mais maintenant on choisi si son code est rattaché au père, à la mère ou aux deux.

C'est d'ailleurs notre choix, et elle apparaît aussi sur la carte de sa mère (c'est donc sacrément plus simple quand elle doit l'emmener chez le médecin sans moi !)

En pièce jointe l'attestation de droits en question (ne me demande pas ce que je fous avec au boulot).