PHP|Débutant :: Forums

Bonjour Mk,

Merci pour ta réponse. Pour tout te dire et pour commencer, cela ne me dérangerait pas d'y contribuer aussi. Je partage ton opinion à savoir que la modélisation et la conception sont les fondements indiscutables des bases de données, et bien que leur nécessité préalable à toute bonne exploitation d'un SGBDR le sont aussi, je reste un peu dubitatif quant à l'intérêt d'un tel tuto hors d'un contexte de suivi et d'apprentissage "scolaire".
En effet, pour t'exprimer un peu le fond de ma pensée en te disant cela, la conception et la modélisation d'une BD, bien que parfaitement définissables et explicables, peuvent relever très vite du domaine de l'abstrait pour des débutants. Ils risquent fortement de s'y perdre voire prendre une bonne dose d'aspirine, pour finalement laisser tomber et ne pas en voir un intérêt immédiatement exploitable. Or on est bien d'accord que c'est un passage obligatoire car il existe autant de modélisations que de cahier des charges de production avec pour seuls points communs ces mêmes fondements.
En ce qui me concerne, pour ne pas mettre de côté ton idée, je verrais plutôt en introduction / première partie à ma proposition une vulgarisation des niveaux de normalisation comme angle d'attaque, pour finir avec les schémas types (pour reprendre la mode des patterns objets) de base de données, comme ceux déjà disponibles sur le web (arbres intervallaires, meta-données, etc... par M.Brouard et bien d'autres encore). Peut être que d'y intégrer aussi les types de données et un petit tuto de comment bien les choisir (comme par exemple un BINARY(20) pour un mot de passe haché en SHA1, etc...).

Je pense qu'au delà de ça, et fort malheureusement, je pense que s'aventurer dans quelque chose de plus complet que des règles (expliquées, commentées et documentées) à respecter me paraît bien hasardeux. Je ne sais pas quel est ton sentiment la dessus.

++

EDIT: A me relire, je suis en train de me demander, pour faire les choses correctement, si cela ne reviendrait pas à en faire tout simplement un livre....

Dernière modification par Jc (12-04-2012 12:17:15)

Je n'ai pas l'intention de faire un livre non plus pour diverses raisons personnelles, la tâche n'en est que plus ardue d'ailleurs. Je te remercie de ta proposition de relecture critique, j'apprécie vraiment.
Je profite de l'occasion que m'a donnée notre ami Fanch aujourd'hui sur le forum, pour te dévoiler ma motivation cachée à travers mon idée de tuto sur MySQL 5.5, qui est aussi de démontrer qu'utiliser MySQL ou un SGBDR en général pour ne gérer que la persistence des données n'est tout simplement pas cohérent (pour ne pas utiliser le terme viable), pertinent et est dangereux pour les entreprises sur le moyen et long terme. Cela concerne de plus et surtout aussi les débutants dans leur choix et dans leur compréhension des technologies mises à leur disposition.

++

Dernière modification par Jc (13-04-2012 03:52:53)

Je pense que c'est avant tout une question "d'éducation" et "d'information" et quand tu peux argumenter directement avec les chefs d'entreprise, M.Brouard à raison, ils comprennent de suite où se trouve leurs intérêts, et quels sont les choix à faire en terme de stratégie et de développement. Mais il faut se battre au quotidien quand tu veux faire du travail de qualité et c'est pas tous les jours facile et la tentation de baisser les bras est parfois présente. Tu m'as dit il n'y a pas longtemps un truc du genre "tu croyais vraiment que le monde professionnel était synonyme de sérieux et professionnalisme?..". Et c'est tellement vrai. Si les CMS permettent de gagner du temps aux yeux des entreprises, outre leur gratuité qu'apparente, car les coûts sous-jacents dépassent largement les coûts d'un travail sur mesure (pas au sens de modifications spécifiques d'un CMS) correct, il faut tout de même se rendre à l'évidence que l'utilisation d'un CMS (les principaux uniquement et encore) est majoritairement la seule garantie pour l'entreprise, d'un développement de base correct et maintenable, ce qui est déplorable. C'est d'ailleurs la principale raison au fait qu'ils n'aiment pas changer de développeur. J'ai eu l'occasion recemment de modifier un module prestashop 1.4 de gestion de dépôt de produits. La société qui l'a développé ne s'est même pas donnée la peine pour la partie base de données de se conformer au format existant de prestashop. En gros tu ne peux même pas faire une jointure sur un id_produit du module avec un id_produit de prestashop et je ne te parle pas du reste sur ce point. C'est bien la demonstration que sur un CMS comme prestashop qui n'est pas si mal que ça entre nous car c'est un des rare à permettre une gestion BD dans les règles de l'art, cette liberté est de suite mise à contribution pour faire nimp, histoire de réduire les coûts.
Pour les menus, si tu me le permets, dans un contexte applicatif (intranets, logiciels en paas et saas, etc..) les menus se doivent d'être dynamiques car les accès aux fonctionnalités dépendent du niveau de l'utilisateur et de ses prérogatives sur la plateforme. Pour un site vitrine et la plupart des sites ecommerce, je te le concède ce besoin est inexistant.
Pour de ce que l'on entends autour de nous, et voit sur internet, il y a heureusement des bons retours ou des bonnes remarques, mais force est de constater également que les efforts consentis à s'orienter en dev épais du côté SGBDR sont toujours minimalistes, c'est à dire quand ils n'ont pas le choix. Cette culture de la performance et du dév SGBDR épais ou presque on ne la trouve que chez les grands comptes ou presque, parce que chez eux, la milliseconde de gagnée x 2000 personnes par jour (il faudrait compter par traitement donc c'est beacoup plus) cela fait des centaines de milliers d'euros d'économies à la fin de l'année pour ne citer que cet exemple. Un exemple récent d'un éditeur qui à fait le choix pour leurs logiciels développés en C#/C++ de passer par des procédures stockées et quelques triggers, cela a été uniquement pour éviter de recompiler systématiquement le code source à chaque ajustement au niveau BD du logiciel.
Il faut dire aussi, que développer en SGBDR épais c'est architecturer ses applications à contre courant aussi, car les besoins doivent être complètement repensés face par exemple à une architecture ZEND, mais quel plaisir, simplicité et les performances donnent du baume au coeur et quand on livre, une certaine fierté est là et les entreprises sont reconnaissantes très rapidement. Quand on travaille sur des modélisations de plus d'une centaine de tables avec des milliers d'enregistrements, et qu'un simple DELETE FROM xxx WHERE id=Y suffit pour supprimer une entrée référencée dans plus de la moitié d'une telle structure en conservant l'intégrité et la consistence des données, les développeurs de CMS sont déjà perturbés^^. A côté de cela qui va utiliser un ZEND ou DRUPAL pour architecturer la gestion d'affichage et d'interaction d'un site d'une façon exclusive et laisser la gestion des données au SGBDR (même si ZEND ne le permets pas vraiment)?
Tes questions sont légitimes, mais ils nous appartient de les faire changer.

Dernière modification par Jc (13-04-2012 13:37:50)