La normalisation de la base de données est-elle morte? [fermé]

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)

L'une des raisons de la normalisation est de supprimer les anomalies de modification des données. Les
ORM ne le prennent généralement pas en charge.

J'ai de nombreux exemples de bases de données conçues par Hibernate qui enfreignent ce principe:

• ballonné (chaîne répétée sur 100s de millions de lignes)
• pas de tables de recherche (voir ci-dessus)
• pas de DRI (contraintes, clés)
• index cluster varchar
• tables de liens inutiles (par exemple, appliquer 1..0: 1 lorsqu'une colonne FK nullable suffirait)

Le pire que j'ai vu est une base de données MySQL de 1 To qui était peut-être 75 à 80% trop grande à cause de ces

Je suggérerais également que l'énoncé «les systèmes d'aujourd'hui peuvent le gérer» est vrai pour la plupart des systèmes Mickey Mouse. À mesure que vous évoluez, les systèmes d'aujourd'hui ne le feront pas.

Dans mon exemple ci-dessus, il n'y avait aucune traction pour refactoriser ou modifier les clés ou corriger les données: il suffit de se plaindre des taux de croissance de la base de données et de l'incapacité à créer un DW significatif par-dessus

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.

Les clés de substitution ne cassent pas 2NF. 2NF indique "Si une colonne ne dépend que d'une partie d'une clé à valeurs multiples, supprimez cette colonne dans une table distincte."

Ils stipulent qu'il est juste préférable d'avoir tout comme une grande table, peu importe si elle a une tonne de null

Avoir plusieurs colonnes dans une table est valide tant que les règles de normalisation sont respectées. Il n'est pas correct de fusionner des tables sans analyse si vous souhaitez profiter des avantages de SQL et de la normalisation.

Je suis d'accord que les contraintes de mémoire ont eu une corrélation directe avec la normalisation Relation Normal Forms est un concept mathématique et n'a rien à voir avec la mémoire.

La normalisation est là non seulement pour économiser de la mémoire ou du disque, elle est là pour ajouter de l'intégrité. Après tout, c'est un concept mathématique indépendant du matériel.

Exemple simple: supposons que vous conserviez les informations sur l'école comme:

Rec 1: North Ridge High School, Californie, États-Unis

Rec 2: South Toronto Braves High School, Ontario, Canada

Si vous demandez à votre système où se trouve l'Ontario, vous pouvez découvrir qu'il se trouve au Canada. Quelques jours plus tard, vous supprimez la deuxième ligne et posez la même question au système et vous n'obtenez rien. Dans cet exemple, peu importe l'espace disque, la mémoire ou le processeur, vous n'obtiendrez pas la réponse.

Il s'agit d'une anomalie qui normalise les relations et aide à prévenir.

Edit: changé le mot Toronto en Ontario selon le commentaire ci-dessous.

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.

Je suis d'accord que les contraintes de mémoire ont eu une corrélation directe avec la normalisation ...

Les contraintes de mémoire comptent toujours. La quantité n'est pas un problème, la vitesse l'est.

• Les processeurs ne sont pas plus rapides pour le moment (nous obtenons plus de cœurs, pas de cycles par seconde)
• Les architectures CPU modernes tentent de surmonter la limitation de vitesse en fournissant une mémoire distincte pour chaque processeur ( NUMA ).
• Les tailles de cache sur puce n'augmentent pas à un rythme comparable à la mémoire principale.
• Le débit de mémoire n'est pas aussi élevé que la plupart des gens s'y attendent. QPI est de l'ordre de 25 Go / sec.

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.

À 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.

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.