Les relations sont-elles plus lentes qu'une grande table inefficace?

On m'a demandé dans mon travail de violer plusieurs fois la première forme normale (répétition de groupes sur plusieurs colonnes, en utilisant des valeurs vides / nulles), "pour la puissance de traitement informatique". En un mot, une table "étudiant" devrait avoir au moins 8 champs vides (par exemple téléphones: téléphone1, téléphone2, téléphone3 ...) au lieu de ma suggestion - une table "téléphone" qui contient un numéro de téléphone (et éventuellement d'autres métadonnées) et la clé étrangère est le numéro d'identification de l'étudiant. Mon patron dit qu'il vaut mieux les stocker de cette façon car "il y a moins de cycles CPU et c'est important dans les plateformes web", au lieu d'utiliser des relations. Je dis que, dans le pire des cas, c'est négligeable.

Dans cet exemple, l'utilisation de relations (supposons que les tables sont remplies de nombreux enregistrements dans une webapp de taille moyenne) est considérablement plus lente que l'utilisation de ce type de schéma de table?

— AeroCross
source

Je pense que ce serait en fait plus rapide à faire comme le dit votre patron, mais vous avez peut-être la tâche atroce de vous assurer de ne pas obtenir d'anomalies de mise à jour. Mais cela pourrait créer beaucoup plus de travail sur le processeur si vous avez besoin de modifier un élément de données commun à la table (changez également l'indicatif régional pour tous les numéros de téléphone ...)

— Patrick

Je doute sérieusement, sur du matériel moderne, à condition que vous ayez indexé vos clés étrangères que le processeur supplémentaire soit même mesurable, en particulier de l'autre côté d'un serveur Web. Sur mon site, nous avons des tables normalisées et servons bien au nord de 50 000 coups / sec sans transpirer. Dites à votre patron de s'en tenir au golf et de vous laisser les décisions techniques!

— Gaius

@Patrick Croyez-vous que c'est considérablement plus rapide ou juste légèrement plus rapide? Et je pense tout comme @Gaius - sur le matériel moderne, même s'il est "plus rapide", le gain de vitesse et de durabilité du matériel est négligeable.

— AeroCross

Je pense que l'amélioration de la vitesse est sans conséquence. Ce n'est que si vous disposez d'ensembles de données massifs et que vous effectuez des jointures ridicules que vous constaterez une différence notable dans les performances.

— Patrick

Je ne vois pas comment quelqu'un pourrait faire une telle déclaration sans avoir des faits réels pour la soutenir. Si vos requêtes sont liées au processeur, vous devez rechercher des moyens de réduire ce goulot d'étranglement.

Il semble que votre patron pense qu'une base de données dénormalisée fonctionnera mieux, mais je ne connais pas suffisamment votre application pour dire si c'est vrai ou non. Quel sera le nombre attendu de suppressions, mises à jour et insertions pour cette table?

Je m'attendrais à ce qu'une telle conception dénormalisée puisse entraîner une réduction du temps processeur, mais je m'attendrais à ce que les E / S de votre disque augmentent. Et les lectures physiques à partir du disque coûteront beaucoup plus cher qu'un cycle CPU, alors peut-être que votre patron a une métrique très spécifique à respecter (CPU) et par conséquent veut une conception très spécifique? Si c'est le cas, je construirais simplement ce qui est demandé et conserverais les mesures sur le coût du processeur pour les requêtes en cours d'exécution. Si vous constatez une augmentation du temps, vous pouvez proposer des modifications de conception.

En fait, c'est probablement une bonne idée d'obtenir une liste de toutes les mesures que votre patron veut voir et de les suivre au fil du temps.

— SQLRockstar
source

Le fait est qu'il est de la vieille école - à son époque (20 ans?) Peut-être que c'était important, comme il le propose, mais le matériel et les logiciels d'aujourd'hui sont beaucoup, beaucoup plus puissants, et ils sont, par conception, plus rapides de cette façon. Il est difficile de traiter avec quelqu'un comme ça, car il a plus de pouvoir et le "fait" empirique (mais dépassé) qu'il est plus rapide, et il devrait être considéré de cette façon.

— AeroCross

compris. essayez de lui faire lister les métriques (CPU, disque I? O) qu'il veut mesurer, et ce qu'il considère comme acceptable. puis mesurez simplement ces éléments et lorsque les choses tournent mal, vous pouvez proposer des alternatives. de cette façon, vous pouvez obtenir une meilleure conception déployée sans combat; laissez simplement son design faire ses preuves au fil du temps. c'est un gagnant-gagnant, en fait.

— SQLRockstar