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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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)

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.