Pourquoi de nombreuses conceptions ignorent la normalisation dans les RDBM?
Je dois voir de nombreuses conceptions que la normalisation n'était pas la première considération en phase de prise de décision.
Dans de nombreux cas, ces conceptions comprenaient plus de 30 colonnes et l'approche principale était "de tout mettre au même endroit"
Selon ce que je me souviens de la normalisation, c'est l'une des choses les plus importantes et les plus importantes, alors pourquoi est-il tombé si facilement parfois?
Edit :
Est-il vrai que de bons architectes et d'experts choisissent une conception dénormalisée tandis que les développeurs non expérimentés choisissent le contraire? Quels sont les arguments contre démarrer votre conception avec la normalisation à l'esprit?
- Beaucoup de développeurs ne connaissent ni ne se soucient de la normalisation, de la modélisation de données ou de la base de données.
- Pour certains emplois, ce n'est vraiment pas important.
- Parfois, il y a une très bonne raison de désalormaliser, par exemple pour rendre une charge de travail difficile particulière.
- Les concepts de base de données relationnels sont récemment moins à la mode qu'elles étaient dans les années 1990 et 2000. Les développeurs ont tendance à être influencés par la mode, même s'ils prétendent être très rationnels. Il ne sert à rien de discuter du goût.
La normalisation est également, historiquement, un territoire pour un argument proche religieux, alors j'hésite à en dire beaucoup plus.
Dans les grands projets, et particulièrement ceux des ordinateurs centraux, ce n'est pas le cas. En fait, si vous recherchez des emplois, vous verrez plusieurs postes pour les modélisateurs de données. En outre, avoir de nombreuses colonnes sur une seule table ne va pas contre la normalisation. Néanmoins, votre observation est valable pour certains projets.
La conception de la base de données est l'une des compétences requises pour créer des systèmes de qualité. Cela dit, certains développeurs ne savent pas assez sur la conception de la base de données et sont toujours assignés à la tâche de la modélisation des données et de la conception de la base de données. Certains projets ignorent même la modélisation des données. L'accent mis sur de nombreux projets concerne principalement le codage et la conception frontale.
Un autre facteur pour la conception de base de données médiocre est le fait que la normalisation n'est pas un sujet trivial spécialement en ce qui concerne la 4ème NF, la 5ème NF, etc. La plupart des livres que j'ai vus ne pouvaient pas bien expliquer ces formes. Il y a généralement de mauvaises exemples et trop de théorie. Cela rend le sujet moins populaire que cela ne devrait.
Les erreurs de la conception de la base de données sont difficiles à trouver à moins que vous ne les recherchiez ou que vous les rencontrez pendant les tests. N'ayant pas de norme pour la qualité de la conception de la base de données permet aux erreurs de se produire plus probables.
Ajoutez à cela le fait que certains projets ne suivent pas une méthodologie de développement rigoureux (un qui favorise la conception de la base de données), par conséquent, les responsabilités sont mixtes et les tâches sont perdues entre l'analyste des affaires, les développeurs et les DBA. Les développeurs parlent dans OO et UML où DBAS parle dans DD et certains dans des ERD et probablement beaucoup ne reçoivent pas UML ou OO. En bref, le manque de connaissances, l'absence de bonnes ressources claires, manque de la langue unifiée pour décrire les données et le manque de méthodologie sont à blâmer.