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