Discussion :

[Targan]

Bonsoir,

2eme sujet coup sur coup car plus j en lis et plus je reste perplexe :

Quel est il preferable de faire ? Optimiser à mort sa base de données ou faire des controles dans l'application qui utilise la base pour eviter au maximum les requetes ?


Et que faire dans certains cas :

* vaut il mieux utiliser un DEFAULT CURRENT_TIMESTAMP ou recuperer la date actuelle dans son appli et l inserer dans sa requete ?

* vaut il mieux mettre NULL ou NOT NULL + valeur par defaut (genre '' pour des varchar, -1 ou 0 pour des int etc...) ?

* vaut il mieux rajouter des contraites style CHECK (EMAIL LIKE %@%) ou faire un controle dans son appli d'autant que bien souvent on stoppe le traitement ou annule la requete (rollback) si elle ne repond pas aux criteres ?

* vaut il mieux s'acharner a bien creer tous les index (pour accelerer les recherches, generalement multi colonnes) ou la base s en charge de toute facon automatique a un certain moment ?

* certaines bases (comme mysql) emettent des warning pour une colonne utilisée en index (colonne seule) et dans un index unique à multiples colonnes, faut il ignorer ce genre de warning ?


Merci à ceux qui donneront qq indications a suivre....

Bonne soiree.

[Antoun]

Bonsoir,

2eme sujet coup sur coup car plus j en lis et plus je reste perplexe :

Quel est il preferable de faire ? Optimiser à mort sa base de données ou faire des controles dans l'application qui utilise la base pour eviter au maximum les requetes ?

Normalement, le principe est que ta base doit être le plus indépendante possible de ton appli. En effet :

1. L'appli représente souvent 99% des utilisations de la base, mais rarement 100% ; en effet, il va toujours y avoir un moment où on va importer des données externes, monter des passerelles de transfert, voire même développer une seconde appli (autre besoin ou autre techno). Si tes contrôles sont sur ton appli, ils seront court-circuités dans tous ces cas-là (par exemple, dans la fac où je bossais avant, on s'est retrouvés avec des étudiants dont les années de naissance allaient de 970 à 2085 ).
2. Il s'agit de gérer des données, et a priori c'est le SGBD qui est là pour ça et qui est le mieux placé pour le faire.
3. Il est généralement plus simple de poser des règles sur la base que de programmer ces mêmes règles (pas sûr que tout le monde soit d'accord ) ; inversement, cela permet d'éviter de polluer le code de l'appli avec des tonnes de lignes qui relèvent d'une logique de données plutôt que d'une logique applicative.

ça suppose par contre :

1. que la base renvoie des messages d'erreur suffisamment explicites et complets
2. que l'appli sache les gérer et les interpréter

Et que faire dans certains cas :

* vaut il mieux utiliser un DEFAULT CURRENT_TIMESTAMP ou recuperer la date actuelle dans son appli et l inserer dans sa requete ?

Récupérer la date actuelle dans l'appli suppose qu'ensuite il faudra la transcoder en SQL et l'insérer dans une requête... ce n'est performant ni pour le système informatique, ni pour le développeur !
A l'inverse, quand tu as la possibilité de faire une date de création automatique (comme par exemple le DEFAULT CURRENT_TIMESTAMP), il suffit de le paramétrer une fois pour toutes et ensuite tu n'as même pas à le mentionner dans tes requêtes !
J'ajouterais que pour les cas où tu veux insérer la date courante dans une colonne où ce n'est pas la valeur par défaut, tu ne passes surtout pas par le code applicatif mais simplement en utilisant CURRENT_DATE, SYSDATE ou autre dans le code SQL.

* vaut il mieux mettre NULL ou NOT NULL + valeur par defaut (genre '' pour des varchar, -1 ou 0 pour des int etc...) ?

Il faut utiliser ce qui est naturel et éviter d'inventer des conventions tordues. Supposons que tu gères une bibliothèque, et que tu recenses les prix d'achats de tes bouquins. Un prix 0 veut dire que tu as eu le livre gratuitement. Un prix NULL veut dire que tu ne sais pas quel était le prix. Si tu fais une requête pour calculer le prix moyen, les 0 vont faire baisser ta moyenne, tandis que les NULL seront ignorés.

* vaut il mieux rajouter des contraites style CHECK (EMAIL LIKE %@%) ou faire un controle dans son appli d'autant que bien souvent on stoppe le traitement ou annule la requete (rollback) si elle ne repond pas aux criteres ?

CHECK ! cf mon exemple des dates de naissance ci-dessus.
L'inconvénient, surtout en développement web, est que ça suppose qu'on accepte les saisies incohérentes pour les refuser ensuite... il m'est fréquemment arrivé de développer en double la validation des saisies :

1. en SQL au niveau de la base, pour bétonner l'intégrité
2. en JavaScript au niveau des pages web, pour le confort des utilisateurs

Evidemment, ça suppose une double maintenance

* vaut il mieux s'acharner a bien creer tous les index (pour accelerer les recherches, generalement multi colonnes) ou la base s en charge de toute facon automatique a un certain moment ?

La base ne créera jamais d'index automatiquement.

Joker pour la dernière question

[Targan]

Interessantes ces explications detaillees.

Certaines m'ont apporté un vrai eclaircissement sur ce que je dois faire, d'autres moins car je pense que ca depend du contexte, de l'appli et de son envergure mais je m'efforcerai de suivre ces directives ^^

En tout cas, un grand merci !

[GrandFather]

Certaines m'ont apporté un vrai eclaircissement sur ce que je dois faire, d'autres moins car je pense que ca depend du contexte, de l'appli et de son envergure mais je m'efforcerai de suivre ces directives ^^

Disons qu'il existe à l'heure actuelle deux approches un peu antagonistes de l'intégration des SGBDR dans une application :

• l'approche "old school", présentée par Antoun, qui place la conception relationnelle au premier plan (formes normales, règles d'intégrité, etc.) et qui rend totalement indépendante la base de données de la couche applicative.
• l'approche "moderne", basée sur le data binding et les ORM, qui privilégie la modélisation objet, et qui assujettit complètement le SGBDR en n'en faisant que le support de persistence des objets modélisés

Chaque approche a ses fervents défenseurs et ses adversaires, et les arguments en faveur ou en défaveur de l'une ou l'autre ne manquent pas. En voici une liste, forcément incomplète :

• Les avantages de l'approche "old school" ont été développés par Antoun, je n'y reviendrais pas. Les désavantages sont la nécessité d'un niveau de maîtrise de SQL et des spécificités des différents SGBDR par toujours évident à atteindre, et la redondance de code (les règles métiers sont le plus souvent dupliquées entre le SGBDR et l'application)
• L'approche "moderne" permet à des néophytes en SQL d'utiliser un SGBDR pour conserver leur données, le framework se charge de tous y compris de construire la base, et le choix du SGBDR à utiliser, souvent assez délicat dans l'approche "old school", devient secondaire. Le problème est que les développeurs n'ayant plus vraiment la "main" sur la base de données, ils sont assez désemparés lorsqu'il est nécessaire de procéder à de l'optimisation ou de résoudre des problèmes pointus liés au SGBDR. De plus, les erreurs d'implémentation des règles métiers dans l'application ont plus de répercussions, puisqu'il ne faut plus compter sur les contrôles implémentés dans la base elle-même pour les faire respecter

Personnellement, je suis un tenant de la méthode "old school". Les données sont le véritable trésor de l'entreprise, et les préserver est un objectif primordial. Le pire des scénarios pour moi est de devoir interrompre un service le temps de restaurer des données corrompues à cause d'un bug dans une application... Maintenant, l'approche "moderne" est très séduisante par les gains importants de productivité qu'elle apporte, et par la possibilité qu'elle offre d'une conception 100% objet. A mon avis, on devrait atteindre le nirvana du développement avec SGBDR en employant un subtile mélange des deux.

[Antoun]

[LIST][*]l'approche "old school", présentée par Antoun, qui place la conception relationnelle au premier plan (formes normales, règles d'intégrité, etc.) et qui rend totalement indépendante la base de données de la couche applicative.

[TROLL_MODE]
Yes. La modélisation objet, c'est très bien pour faire joujou avec des interfaces utilisateur, mais pour gérer des données, autant utiliser un outil adapté.
[/TROLL_MODE]

Ceci dit, ce débat ne s'applique qu'à l'aspect "contrôles sur l'appli ou sur le SGBD". Pour ce qui est des dates et NULL, je pense que même les objectistes devraient être d'accord.