J'ai été élevé à l'ancienne - où nous avons appris à concevoir le schéma de base de données AVANT la couche métier de l'application (ou à utiliser OOAD pour tout le reste). J'ai été assez bon pour concevoir des schémas (à mon humble avis :) et normalisé uniquement pour supprimer la redondance inutile, mais pas là où cela a eu un impact sur la vitesse, c'est-à-dire que si les jointures étaient un problème de performances, la redondance était laissée en place. Mais ce n'était généralement pas le cas.
Avec l'avènement de certains cadres ORM comme Ruby ActiveRecord ou ActiveJDBC (et quelques autres dont je ne me souviens pas, mais je suis sûr qu'il y en a beaucoup), il semble qu'ils préfèrent avoir une clé de substitution pour chaque table même si certains ont des clés primaires comme 'e-mail' - cassant carrément 2NF. D'accord, je ne comprends pas trop, mais cela me fait (presque) peur quand certains de ces ORM (ou programmeurs) ne reconnaissent pas 1-1 ou 1-0 | 1 (c'est-à-dire 1 à 0 ou 1). Ils stipulent qu'il est juste préférable d'avoir tout comme une grande table, peu importe si elle a une tonne de nulls "systèmes d'aujourd'hui peuvent le gérer", c'est le commentaire que j'ai entendu le plus souvent.
Je suis d'accord que les contraintes de mémoire ont eu une corrélation directe avec la normalisation (il y a aussi d'autres avantages :) mais à l' heure actuelle avec la mémoire bon marché et les machines quad-core, le concept de normalisation DB est-il laissé aux textes? En tant que DBA, pratiquez-vous toujours la normalisation à 3NF (sinon BCNF :)? Est-ce que ça importe? La conception de "schéma sale" est-elle bonne pour les systèmes de production? Comment doit-on plaider en faveur de la normalisation si elle est toujours pertinente?
( Remarque: je ne parle pas des schémas en étoile / flocon de neige de Datawarehouse qui ont une redondance en tant que partie / besoin de la conception, mais des systèmes commerciaux avec une base de données principale comme StackExchange par exemple)
la source
Plus les choses changent, plus elles restent les mêmes. Il y a toujours eu des développeurs paresseux qui ont fait des économies ou ne savent tout simplement pas ou veulent suivre les meilleures pratiques. La plupart du temps, ils peuvent s'en tirer avec de petites applications.
Auparavant, il intégrait des structures de données inspirées de COBOL dans les premiers SGBDR, ou le désordre horrible qui était dBase. Maintenant, ce sont les ORM et "Code-First". En fin de compte, ce ne sont que des façons pour les gens d'essayer de trouver la solution miracle pour obtenir un système qui fonctionne sans «perdre» de temps à réfléchir sérieusement à ce que vous voulez et devez faire. Être pressé a toujours été un problème et le sera toujours.
Pour ceux qui ont le bon sens (et la bonne chance) de prendre le temps de bien concevoir, le modèle de données sera toujours l'endroit le plus logique pour commencer. La base de données contient des informations sur les choses (tangibles et intangibles) qui intéressent votre entreprise. Ce qui importe à votre entreprise change beaucoup moins rapidement que la façon dont elle fonctionne. C'est pourquoi votre base de données est généralement beaucoup plus stable que votre code.
La base de données est le fondement légitime de tout système et prendre le temps de poser correctement vos fondations vous sera inévitablement bénéfique à long terme. Cela signifie que la normalisation sera toujours une étape importante et utile pour toute application de type OLTP.
la source
Les contraintes de mémoire comptent toujours. La quantité n'est pas un problème, la vitesse l'est.
Une partie de ce motif a été abordée dans Quand utiliser TINYINT sur INT? que vous pourriez trouver utile. Je suggère également de suivre les ébats de @ThomasKejser ( blog ) de l'équipe SQLCAT, car ils ont tendance à être à la pointe de la performance des bases de données. Le récent article sur L'effet des caches CPU et des modèles d'accès à la mémoire et la présentation SQLBits sur la modélisation relationnelle pour Extreme DW Scale en sont de bons exemples.
la source
À mon avis, il s'agit toujours d'un équilibre entre normaliser et dénormaliser . Je suis totalement d'accord que les cadres ORM ne sont que des approches pour faire avancer les choses, mais je ne pense pas que ce sont ces cadres qui provoquent la tendance à la dénormalisation .
c'est toujours ce débat que vous voulez l'efficacité du temps ou vous voulez l'efficacité de l'espace. Au moment où la théorie de la base de données relationnelle est évoquée, le stockage sur disque coûte cher, les gens ne veulent évidemment pas dépenser autant d'argent là-dessus, c'est pourquoi à ce moment-là, les bases de données relationnelles sont celles qui restent fermes dans les adversités
De nos jours, les choses sont très différentes, le stockage est très très bon marché. Alors évidemment on peut tolérer plus de redondance par rapport à l'ancien temps, c'est aussi POURQUOI l'approche BIG_TABLE est apparue. afin de rechercher plus d'efficacité de temps, l'efficacité de l'espace doit être sacrifiée.
Mais, l'approche Big-table n'est pas non plus la fin de l'histoire, c'est toujours l'équilibre entre le temps et l'espace, en termes de données de volume PB à gérer, certains développeurs ont également commencé à chercher l'équilibre vers l'efficacité de l'espace, c'est pourquoi il sont des travaux effectués pour normaliser certaines données dans des structures de type BIG-TABLE.
En un mot, l'approche de normalisation n'est pas définitivement morte, mais par rapport à l'ancien temps, elle est définitivement négligée.
la source
CJ Date répond à votre question ici - la vidéo de normalisation (prélim) est gratuite.
http://shop.oreilly.com/product/0636920025900.do
La réponse courte: la normalisation est la façon mathématiquement correcte de faire les choses. Si vous ne normalisez pas correctement, votre modèle de données est tout simplement incorrect.
la source