Mon collègue a créé une table SQL à 96 colonnes

23

Nous voici en 2010, ingénieurs logiciels avec 4 ou 5 ans ou expérience, toujours en train de concevoir des tables avec 96 colonnes de fracturation.

Je lui ai dit que ça allait être un cauchemar.
Je lui ai montré que nous devons utiliser des ordinaux pour interfacer MySQL avec C #.
J'ai expliqué que les tableaux avec plus de colonnes que de lignes avaient une énorme odeur.

Pourtant, je reçois le "ça va être plus simple de cette façon".

Que devrais-je faire?

MODIFIER *

Ce tableau contient les données des capteurs.
Nous avons le capteur 1 avec
Dynamic_D1X
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

Eh bien, j'ai finalement quitté ce travail. C'est un signe lorsque l'autre programmeur s'assombrit pendant des mois à l'époque, c'est un autre signe lorsque la direction ne se rend pas compte que c'est un problème

Eric
la source
5
Uggh, pourrait aussi bien être l'âge sombre. Quand les gens apprendront-ils comment utiliser les bases de données?
ChaosPandion
49
Tu propose quoi? Vous ne pouvez pas simplement être exaspéré par un problème si vous n'avez pas de solution.
TGnat
1
Je suis curieux de savoir ce qui est stocké dans chaque rangée.
MetalMikester
1
@ChaosPandion, seulement longtemps après l'utilisation des bases de données traditionnelles est en soi une odeur de conception.
instanceofTom
3
Eh bien, il surpasse clairement votre base de données. Nous avions l'habitude d'avoir une base de données avec une seule table avec seulement 4 colonnes varchar: CLASS, OBJECT, ATTRIBUTE, VALUE. Toutes les données y tiennent. Bas ça! :)
Lukas Eder

Réponses:

32

Peut-être qu'il l'a fait pour une bonne raison, comme les performances ou le retour sur investissement? .

La meilleure chose à faire est de lui poser des questions. Avec un certain «pourquoi», vous lui ferez certainement comprendre qu'il a probablement tort en lui-même (s'il l'est vraiment).

J'ai moi-même eu un cas qui n'est pas lié aux performances mais au retour sur investissement (ROI). J'avais une table contenant des objets qui avaient une valeur spécifique pour chaque heure de la semaine (168h dans une semaine). Nous avons eu le choix de créer une table ObjectHour qui contiendrait la valeur, mais aussi une clé de l'objet et le numéro du jour du numéro d'heure. Mais nous avons également eu l'occasion de mettre les 168 valeurs directement dans la rangée. Probablement comme ce qu'a fait votre collègue.

Les développeurs ont estimé les deux solutions. La solution simple (168 colonnes) était beaucoup moins chère à faire que son homologue bien conçue. Pour le même résultat exact pour le client.

Nous avons décidé d'opter pour la solution simple / la moins chère pour concentrer nos efforts sur des choses plus importantes telles que la sécurité.

Nous aurons de nombreuses occasions d'améliorer cela à l'avenir. Le time to market était la priorité pour nous à l'époque.


la source
3
Je suis d'accord - sans contexte supplémentaire au «pourquoi», le nombre de colonnes n'a pas vraiment d'importance. Il pourrait légitimement avoir 96 éléments à suivre ... ou, il peut utiliser des colonnes supplémentaires pour des "tableaux" de données (nom_1, nom_2) qui devraient être divisés en d'autres tables.
GrandmasterB
Oh tu me fais me souvenir d'une chose ... je vais l'ajouter à ma réponse
1
«normalisé» n'implique pas nécessairement «bien conçu». Je considérerais la dénormalisation que vous décrivez ici comme une décision de conception parfaitement fine.
1
Je suis entièrement d'accord avec @GrandmasterB. Le nombre de colonnes n'est pas quelque chose qui peut être jugé indépendamment. Il y a des moments où beaucoup de données connexes doivent être stockées sur une seule chose. Que doivent faire les gens? Faire un tableau de données balisées (id, tag, value)et INSERTquatre - vingt - dix lignes impaires? Si les informations appartiennent à une table et sont justifiées, la colonne reste, à moins qu'elle ne cause un problème de performance horrible.
Orbling
+1 La dénormalisation est nécessaire pour certaines applications. Je dirais que les bases de données ne sont pas des feuilles de calcul. Ce n'est pas parce qu'ils ont un format de tableau similaire que les bases de données doivent être lisibles par l'homme. Il s'agit d'un stockage back-end de données et doivent être traités comme tels.
Evan Plaice
17

Malheureusement, votre développeur moyen considère toujours les bases de données relationnelles comme de gros fichiers plats. La seule façon de s'améliorer, c'est si quelqu'un prend les choses en main et donne l'exemple. Tout récemment, j'ai dirigé une refonte majeure d'un schéma important dans notre base de données et j'ai suivi les pratiques relationnelles courantes. Tout à coup, nos procédures stockées étaient plus élégantes et tous les index appropriés semblaient se mettre en place comme s'ils étaient nés pour cela. Le développeur axé sur l'ego ne vous croira jamais sans preuve.

ChaosPandion
la source
2
Parfois, il faut des preuves pour convaincre quelqu'un qui est déjà convaincu qu'il a raison. +1
Chris
1
Vraiment? Le développeur moyen fait cela? Oui.
webbiedave
Peut-être que les gros fichiers plats sont ce dont ils ont besoin en premier lieu;)?
Job
pas nécessairement l'ego, mais pourquoi changer? Les nouveaux trucs doivent être bien mieux «payés» pour le temps et les efforts consacrés à leur utilisation.
-1 il existe des raisons parfaitement valables d'utiliser un tableau de données dénormalisé. Par exemple, que se passe-t-il si vous devez le partager sur de nombreux serveurs parce que l'ensemble de données est devenu trop volumineux ou que vous avez besoin d'un temps d'accès à la latence extrêmement faible (dites au revoir à l'utilisation des jointures).
Evan Plaice
11

Quelque chose de similaire a été discuté précédemment sur StackOverflow .

En général, avoir beaucoup de colonnes sur une table ne signifie pas nécessairement que vous faites quelque chose de mal, mais cela devrait certainement soulever des drapeaux rouges afin que vous examiniez attentivement la conception. Parfois, une énorme table est le bon choix, mais dans de nombreux cas, d'autres alternatives ont plus de sens. Par exemple, une option consiste à diviser le stockage en deux tables: une table qui identifie vos entités et une autre table qui est en fait un magasin de clés / valeurs d'attributs décrivant ces entités (vous pouvez donc vous retrouver avec au plus 96 lignespour chaque entité). D'autres conceptions sont également possibles. Discutez avec vos coéquipiers et déterminez la meilleure solution en fonction de la normalisation des données, de la lisibilité et de la maintenabilité du code (insérer des instructions avec 96 attributs à remplir?), Des implications en termes de performances, de la fréquence à laquelle de nouveaux attributs (colonnes) pourraient être ajoutés ou modifiés, de la rareté les données sont (combien des 96 colonnes seront jamais remplies et combien restent NULES?), et les implications sur les rapports. Tout développeur doit pouvoir raisonnablement justifier ses décisions de conception et montrer que le compromis coût / avantage (et oui, chaque décision de conception est un compromis) est en sa faveur. Votre responsabilité n'est pas de vous plaindre ou de critiquer, mais de proposer des alternatives et de vous assurer qu'ils ont réfléchi à ces questions.

Yevgeniy Brikman
la source
1
les magasins de valeur clés sont presque toujours le pire choix pour la performance et la fiabilité.
HLGEM du
8
Envie d'élaborer?
Yevgeniy Brikman
9

Est-il normalisé avec 96 colonnes? Satisfait-il aux 1er, 2e, 3e etc NF?

Il se peut que vous ayez 96 attributs distincts pour une entité.

Sinon, faites-lui lire Joe Celko sur Simple Talk

gbn
la source
5

Cela dépend complètement.

Les conceptions DB normalisées / non normalisées ont toutes deux leurs avantages et leurs inconvénients.

Mon premier design DB était une chose normalisée de beauté. Il était flexible et extensible. C'était aussi un PITA incroyable pour tout le monde sauf moi à gérer au niveau du code, et c'était un PITA doux pour moi.

Ma prochaine tentative était une structure plate, et c'était (a) beaucoup plus rapide et (b) beaucoup plus facile à coder. Et ce ne sera pas une énorme corvée de se normaliser plus tard.

Il peut donc s'agir d'une odeur, mais une autre conception de base de données aura sa propre gamme délicieuse d'odeurs.

John
la source
+1 Pour avoir souligné que souvent, il n'y a pas de bonne façon.
Orbling
3

Faites-lui lire cet article sur la dette technique . S'il décide toujours de garder les choses de cette façon, alors au moins vous avez offert un avis constructif.

BradB
la source
1

En regardant le post (édité), il est clair qu'il s'agit d'un tableau mal dénormalisé. Que devrais tu faire? Selon moi, vous avez quelques options:

  1. Criez à votre collègue pour apprendre à faire son travail. Peu susceptible d'être productif, mais convaincra probablement d'autres collègues de ne pas jouer avec vous. Une réputation de maniaque hurlant peut être utile (ne me demandez pas comment je le sais).
  2. Criez au patron que votre collègue est un idiot. Prévoyez une catastrophe, puis travaillez activement à saboter le projet. Blâmer tout sur la conception de la base de données produite par un collègue incompétent. Peut conduire directement à ...
  3. Quitter. Mieux si c'est votre idée, mais # 2 peut conduire à une démission involontaire. Essayez de ne pas gratter les genoux sur l'asphalte / le béton / le gravier s'il est projeté par la fenêtre par un patron et / ou des collègues enragés. (Notez qu'une étude préalable est IMPORTANTE ici. Vos chances de survie diminuent considérablement si le bureau du patron est au-dessus du rez-de-chaussée et que vous vous retrouvez propulsé corporellement par la fenêtre. Planifiez à l'avance !! )
  4. Buvez beaucoup - ou, déménagez en Californie et allumez (en supposant que la prop. 19 (ou autre) passe). Rien de tel que quelques clichés et un doobie pour améliorer son regard sur ses collègues (ou du moins j'ai entendu parler). (Annonce de service public: ENFANTS! Ces gens sont des professionnels! N'ESSAYEZ PAS cela à la maison!)

Partagez et profitez.

Bob Jarvis - Réintégrer Monica
la source
J'ai essayé # 4 mais maintenant c'est lundi et tout sera de retour quand j'arriverai sur le lieu de travail =)
Eric
Lisez le premier point. A voté. Lisez le point deux, j'ai annulé mon vote positif. Sérieusement mec?
Zoran Pavlovic
0

Je vais sortir sur une branche ici et supposer qu'il va couper et coller beaucoup de code pour travailler avec cette "nouvelle" table.

Si tel est le cas, vous n'encourrez probablement aucune dette technique supplémentaire. Il vient de partager sa part de la dette technique et pourrait bien être sur la voie d'une sorte de grande unification des choses.

S'il a une méthodologie éprouvée qui nécessite une colonne de 96 colonnes, considérez les avantages réels de le faire d'une manière différente dans ce cas particulier. S'il n'y en a pas, alors donnez-lui le bénéfice du doute, mais rappelez-lui que la prochaine fois que vous voudrez entrer dans la phase de planification la prochaine fois, il fera ce que nous considérerions tous comme une décision assez stupide.

Peter Turner
la source
0

Dépend totalement des cas d'utilisation de l'application qui va accéder au schéma, de la quantité de données nécessaire à la fois. D'une certaine manière, cela pourrait justifier la conception de la table.

SJha
la source
0

Je l'envoyais à l'âge de pierre et je le forçais à utiliser des fichiers ou au moins à lui apprendre à utiliser des blobs.

Vraiment, 96colonnes ... Ça ne peut pas être vrai, jamais. Peut-être qu'un ORM aiderait. (Sauf si vous avez besoin de performances, mais vous pouvez alors avoir quelqu'un qui comprend mieux DB pour le gérer)


la source
0

Je vais tout voter en enfer pour cela, mais c'est exactement pourquoi j'ai séparé les responsabilités de la modélisation des données et de l'ingénierie logicielle dans ma boutique. Les programmeurs semblent rarement penser sous la forme d'ensembles et se concentrer plutôt sur l'utilisation des données (plutôt que de maintenir la 3e forme normale, l'indexation ou d'autres problèmes de performances de base de données). En tant que programmeurs, nous avons également tendance à être plus en désaccord sur ces décisions architecturales de base de données que nous ne le devrions peut-être, en raison de notre inexpérience en matière de modélisation de données / problèmes d'architecture. À mon humble avis, j'aime avoir des architectes de données et des modélisateurs qui prennent les exigences, construisent des tables / procs / etc., et laissent le soin de gérer les sorties à moi.

Sans connaître les raisons réelles de cette conception (j'ai travaillé sur des capteurs météorologiques qui ont bien plus de 96 sorties numériques différentes = grand nombre de colonnes de tableau) ... cela semble juste évacuer une bête noire.

iivel
la source