Discussion :

[amapic]

Bonjour,

Je dois créer une application avec une table de données pouvant comporter jusqu'à 1 500 000 lignes avec de 4 à 10 métadonnées.
Je voudrais faire une prévision grosso modo du temps de réponse d'une requête simple sur cette table de données. Comment mesurer celà ? Quelles sont les caractéristiques du serveur dont on a besoin pour répondre à cette question ?

Merci beaucoup.

[Invité]

Ça dépend de la taille de la table, des performances attendus et du budget.

Si tu as 0$, fais avec le vieux PC qui traine dans le coin avec ces 2 mo de RAM et une version express.
Avec 250 000$, prends une bête de course avec 250 Go de RAM et du RAID 10 sur tous les volumes.

Est-ce que tu as 150 000 connexions dessus en permanence avec des lectures / écritures incessantes ou bien une unique connexion qui ne fait que de la lecture ?

Mais il reste que si ta bd est mal modélisée et mal indexé, ça sera moins performant que si ça a été réfléchie et travaillé en amont.

Et les requêtes sont-elles optimisées ou c'est écrit à l'arrache avec les souvenirs du cours SQL de la Fac d'il y a 10 ans sous Access ?

Bref, y a pas de réponse toute faite !

[SQLpro]

Plus que du matériel cela dépend de la qualité du modèle de données et par la suite de l'indexation.

le respect du modèle part sur des principes simples :
1) pas de redondance
2) pas de null
3) la mise à jour d'une information ne doit pas impacter plus d'une ligne

Si toutes ces conditions sont respectées, alors l'indexation sera triviales et les performances exceptionnelles !

Dans le cas contraire, ce sera mauvais, même avec un hardware haut de gamme !

A +

[taibag]

Bonjour,

Pour le deuxième point , quel est le désavantage d'utiliser le merquer Null dans une base de données du moment que les SGBDR l'implemente ?

Merci.

[SQLpro]

Bonjour,

Pour le deuxième point , quel est le désavantage d'utiliser le merquer Null dans une base de données du moment que les SGBDR l'implemente ?

Merci.

Imaginez que vous voulez changer d'entreprise en tant que salarié. Vous allez à un entretien avec le patron d'une startup qui vous indique, chiffres et bilan à l'appui que sa boite de 50 employés à une croissance de 70% par an et qu'il a décidé d'investir dans la construction d'un immeuble pour y loger son entreprise... Mais comme il veut pérenniser son investissement immobilier, il vous confie que son immeuble sera prêt à accueillir les 10 000 employés qu'il aura d'ici 10 ans (10 ans de croissance à 70 % avec au départ 50 employés = 10080 employés)...

Maintenant que pensez-vous de ce patron, qui va investir dans un immeuble permettant de loger 10 000 salariés alors qu'il n'en aura que 85 la première année, 144 la suivante, 246 la 3e... ?
Quel sera l'état des bureaux qui auront été vide pendant 9 ans ?
Est-il absolument certain de sa croissance ? Ne va t-elle pas être bien plus grande ? Ou nettement moins grande ?

Personnellement je pense que ce patron est un imbécile !

De la même manière, avoir du NULL dans une base, c'est stocker du vide qui coute cher ! pensez vous que vous aurez de bonne performances en ayant un volume de base X dont les données ne représente que 3% ?

Lisez l'article connexe que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p1...mances_petites

A +

[taibag]

Bonjour SQLpro,

J'ai lu votre article et il est intéressant. Mais entre la théorie et la pratique un grand écart , on ne peut pas éliminer les marquers NuLL, cepandant on peut minimiser leur utilisation. Si vous avez une solution de comment le faire je suis preneur.

Merci

[SQLpro]

Bonjour SQLpro,

J'ai lu votre article et il est intéressant. Mais entre la théorie et la pratique un grand écart , on ne peut pas éliminer les marquers NuLL, cepandant on peut minimiser leur utilisation. Si vous avez une solution de comment le faire je suis preneur.

Merci

D'abord et contrairement à ce que vous pensez on peut éliminer tous les NULL. Il suffit de décomposer l'entité anormalement modélisée en n +1 entités, n étant le nombre d'attributs non clé.
Exemple :
soit la relation Remp (employés) avec les attributs suivants :

• emp_matricule (clef)
• emp_salaire
• emp_poste
• emp_service

La solution consiste à créer 4 relations :

• Remp : emp_matricule
• Remp_sal : emp_matricule, emp_salaire
• Remp_pst : emp_matricule, emp_poste
• Remp_svc : emp_matricule, emp_service

et d'y ajouter une vue de synthèse, qui reforme la "table" originale :

Code :

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

1
2
3
4
5
6
7
CREATE VIEW V_EMP
AS
SELECT E.emp_matricule, S.emp_salaire, P.emp_poste, V.emp_service
FROM   Remp AS E
       LEFT OUTER JOIN Remp_sal AS S ON E.emp_matricule = S.emp_matricule
       LEFT OUTER JOIN Remp_pst AS P ON E.emp_matricule = P.emp_matricule
       LEFT OUTER JOIN Remp_svc AS V ON E.emp_matricule = V.emp_matricule;

N'oubliez pas que les vues peuvent être mises à jour, soit directement (sous certaines conditions) ou indirectement (trigger INSTEAD OF).

Si par exemple vous avez besoin de rajouter l'historique des informations, dans le système monotable, vous allez avoir de la redondance.
Exemple, le salaire du matricule de l'agent X27 passe à 3 900 € ce jour...
Si la table est modélisée comme suit :
Remp (employés) :

• emp_matricule (clef)
• emp_salaire
• emp_poste
• emp_service
• emp_date_application

Alors vous allez vous retrouver avec 2 lignes et par conséquent 2 informations redondantes :

Code :

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

1
2
3
4
emp_matricule    emp_salaire   emp_poste   emp_service   emp_date_application
---------------- ------------- ----------- ------------- ---------------------
X27              2800          espion      chiffrement   1/1/1947
X27              3900          espion      chiffrement   28/4/2015

Les informations "espion" et "chiffrement" sont redondante. Vous violez au moins une forme normale...
Ou bien du NULL...

Code :

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

1
2
3
4
emp_matricule    emp_salaire   emp_poste   emp_service   emp_date_application
---------------- ------------- ----------- ------------- ---------------------
X27              2800          espion      chiffrement   1/1/1947
X27              3900          NULL        NULL          28/4/2015

... ce qui revient à notre problème de départ ! PAS DE NULL !!!

La bonne solution (6e forme normale) consiste à dater chaque information individuellement, car chaque information évolue historiquement en toute indépendance des autres !

La nouvelle solution consiste à utiliser nos 4 relations avec en sus la date d'application de chaque attribut non clef :

• Remp : emp_matricule
• Remp_sal : emp_matricule, emp_salaire, emp_sal_date_applic
• Remp_pst : emp_matricule, emp_poste, emp_pst_date_applic
• Remp_svc : emp_matricule, emp_service, emp_svc_date_applic

Notez que certains SGBD décomposent automatiquement les tables créées exactement comme cela. C'est le cas de Sybase IQ.
Certains autres SGBDR permettent de créer des index qui font la même chose (famille d'index connues sous le nom d'indexation verticale). C'est le cas de Microsoft SQL Server avec le ColumnStore Index.
La plupart des grands éditeurs (Oracle, Sybase, IBM DB2, MS SQL Server) vont d'ailleurs dans ce sens. Il n'y a que les, petits "free" qui ont du mal à suivre....

A +

[taibag]

Vraiment cool tous ça, n'auriez vous pas un livre à vous sur le théorie des relation et la modélisation des données en anglais svp.

Merci.

[SQLpro]

Il y en as pas mal.... Les plus intéressant sont ceux de chris date. Mais il faut au préalable avoir une vision complète de la modélisation. Il y a le pdf de fsmrel sur dvp qui est un bon point de départ, mais en français :
http://fsmrel.developpez.com/basesre...?page=sommaire

Sur les SGBDR d'un point de vu général et global, le livre de chris date : (c'est la référence en la matière)
http://www.amazon.com/dp/0321197844/
Les ouvrages de l'éditeur US Morgan Kaufman sont parmi les ouvrages les plus complets sur la modélisation des données :
http://www.amazon.com/dp/0123820200/
http://www.amazon.com/dp/0123735688/
...
et d'autres :
http://www.amazon.com/dp/0132943263/
http://www.amazon.com/dp/1285085256/
http://www.amazon.com/dp/1111969604/

Une fois que vous aurez bien pénétré le sujet, c'est un régal de lire Chris Date :
http://www.amazon.com/dp/1449328016/
http://www.amazon.com/dp/144936943X/
http://www.amazon.com/dp/0596100124/
http://www.amazon.com/dp/0321399420/
http://www.amazon.com/dp/0128006315/
http://www.amazon.com/dp/1425122906/
http://www.amazon.com/dp/0201708507/
http://www.amazon.com/dp/159059746X/

A +

[taibag]

Je vous remercie vivement pour le temps que vous avez consacré pour me donner ces précieuses informations. je commencerai par la lecture de ce livre :http://www.amazon.com/dp/0321197844/