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
la source
Réponses:
Peut-être qu'il l'a fait pour une bonne raison, comme les performances ou le retour sur investissement? .
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
(id, tag, value)
etINSERT
quatre - 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.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.
la source
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.
la source
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
la source
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.
la source
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.
la source
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:
Partagez et profitez.
la source
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.
la source
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.
la source
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
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.
la source