同僚が96列のSQLテーブルを作成しました

私たちは2010年に、4年または5年以上の経験を持つソフトウェアエンジニアであり、96のフラッキングカラムを持つテーブルを設計しています。

私は彼にそれが悪夢になると言った。
MySQLをC＃とインターフェイスするには序数を使用する必要があることを彼に示しました。
行よりも列の方が多い表は大きな臭いだと説明しました。

それでも、「この方法でもっと簡単になるだろう」というメッセージが表示されます。

私は何をすべきか？

編集*

このテーブルには、センサーからのデータが含まれます。 Dynamic_D1X Dynamic_D1Y
を備えたセンサー1が
あり
ます
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

さて、私はついにその仕事を辞めました。それは、他のプログラマーが何ヶ月も暗くなったときの兆候であり、管理者がこれが問題であることを認識していないときの別の兆候です

たぶん彼はパフォーマンスやROIなどの正当な理由でそれをしたのでしょうか？。

最善の方法は、彼に質問することです。ある量の「なぜ」で、彼はおそらく自分が間違っていることを彼に理解させるでしょう（彼が本当にそうなら）。

私自身、パフォーマンスとは関係なく、投資収益率（ROI）に関連する1つのケースがありました。週の各時間（週に168時間）に特定の値を持つオブジェクトを含むテーブルがありました。値を含むObjectHourテーブルを作成するという選択肢がありましたが、オブジェクトへのキーと時間数の日数も含まれます。しかし、168個の値を行に配置する機会もありました。おそらくあなたの同僚がしたことのように。

開発者は両方のソリューションを推定しました。シンプルなソリューション（168列）は、適切に設計された対応策よりもはるかに安価でした。顧客に対してまったく同じ結果を得るため。

セキュリティなどのより重要なものへの取り組みに焦点を当てるために、シンプルで最も安価なソリューションに進むことにしました。

今後、それを改善する多くの機会があります。当時は、市場投入までの時間が優先事項でした。

残念ながら、平均的な開発者はリレーショナルデータベースを大きなフラットファイルと考えています。彼らがより良くなる唯一の方法は、誰かが責任を持って、例によってリードする場合です。つい最近、データベース内の重要なスキーマの大幅な再設計を主導し、一般的なリレーショナルプラクティスに従いました。突然、ストアドプロシージャはすべてよりエレガントになり、適切なインデックスはすべて、そのために生まれたように所定の位置に収まったように見えました。自我主導の開発者は、証拠なしでは決してあなたを信じません。

StackOverflowで以前に似たものが議論されました。

一般に、テーブルに多くの列があるということは、何か間違ったことをしていることを必ずしも意味しませんが、デザインをよく見るために間違いなく赤旗を上げる必要があります。巨大なテーブルが正しい選択である場合もありますが、多くの場合、他の選択肢がより理にかなっています。あなたが最も96時に終わるかもしれので1あなたのエンティティを識別し、テーブル、効果的にそれらのエンティティを記述する属性のキー/値ストアです別のテーブル（たとえば、一つの選択肢は二つのテーブルにストレージを分割することである行各エンティティ）。他の設計も可能です。チームメイトと話し合い、データの正規化、コードの読みやすさと保守性（記入する96個の属性を持つステートメントを挿入しますか？）、パフォーマンスへの影響、新しい属性（列）を追加または変更できる頻度、スパースに応じて、どのソリューションが優れているかを把握しますデータは（96個の列のうちどれだけが埋められ、何個がNULLのままになりますか？）、レポートへの影響。開発者は設計決定を合理的に正当化し、コストと利点のトレードオフ（そして、はい、すべての設計決定はトレードオフ）が有利であることを示すことができるはずです。あなたの責任は、文句を言ったり批判したりすることではなく、代替案を提案し、彼らがこれらの問題を熟考したことを確認することです。

96列で正規化されていますか？1、2、3などのNFを満たしますか？

エンティティに96個の個別の属性がある可能性があります。

そうでなければ、彼にSimple TalkでJoe Celkoを読んでもらいます

それは完全に依存します。

正規化/非正規化DB設計にはそれぞれ長所と短所があります。

私の最初のDB設計は、標準化された美しさでした。柔軟性と拡張性がありました。また、コードレベルで対処するのは私以外の誰にとっても信じられないほどのPITAであり、私にとっては穏やかなPITAでした。

次の試みはフラットな構造で、（a）より高速で、（b）コーディングがはるかに簡単でした。また、後で正規化するのは大したことではありません。

そのため、匂いかもしれませんが、他のDBデザインには、独自の楽しい匂いがあります。

彼に技術的負債に関するこの記事を読んでもらう。それでも彼がそれをこのままにしておくことに決めたなら、少なくともあなたは建設的な意見を提示しました。

（編集された）投稿を見ると、これがひどく非正規化されたテーブルであることは明らかです。あなたは何をするべきか？私が見るように、あなたにはいくつかのオプションがあります：

1. 同僚に叫んで、彼/彼女/その仕事をする方法を学んでください。生産的である可能性は低いですが、おそらく他の同僚にあなたを混乱させないように説得するでしょう。悲鳴を上げるマニアとしての評判は役に立ちます（どうすればよいかを聞かないでください）。
2. 同僚がバカだとボスに叫ぶ。災害を予測し、積極的に妨害プロジェクトに取り組みます。無能な同僚が作成したデータベース設計のすべてを非難します。に直接つながる可能性があります...
3. 終了する。あなたの考えならベストですが、2番目は不本意な辞任につながる可能性があります。激怒したボスや同僚によって窓から投げ出された場合、アスファルト/コンクリート/砂利の膝を擦らないようにしてください。（注以前の研究では、ボスのオフィスは、地上階より上で著しくあれば生存の減少のあなたのチャンス。ここで重要なこととあなた自身が窓の外の身体推進されて見つける。 事前に計画!!）
4. 大量に飲む-または、カリフォルニアに移動してライトアップする（小道具19（または何でも）が通過すると仮定する）。自分の同僚に対する見通しを改善するためのいくつかのショットやドゥービーのようなものは何もありません（または私は聞いたことがあります）。（公共サービスの発表：キッズ！これらの人々はプロです！自宅でこれを試さないでください！）

共有してお楽しみください。

ここで四肢に出て、彼がこの「新しい」テーブルで作業するために多くのコードをカットアンドペーストすることを想定します。

もしそうなら、おそらく追加の技術的負債を被ることはないでしょう。彼は技術的負債のシェアを分割したばかりであり、物事の何らかの大規模な統一への道を進んでいるかもしれません。

彼が96カラムを必要とするいくつかの実証済みの方法論を持っている場合、この特定のケースで異なる方法でそれを行うことの実際の利点を考慮してください。何もなければ、彼に疑いの恩恵を与えますが、次回、彼が私たち全員がかなり愚かな動きであると考えているものを作るときに計画段階にいたいことを思い出させてください。

スキーマにアクセスするアプリケーションの使用例、一度に必要なデータのチャンクに完全に依存します。何らかの方法で、テーブル設計を正当化するかもしれません。

私は彼を石器時代に送り、ファイルの使用を強制するか、少なくともブロブの使用方法を教えました。

本当に、96columns ...それは正しくありません。ORMが役立つかもしれません。（パフォーマンスが必要な場合を除き、データベースをより適切に処理できる人がいる場合があります）

私はこれのためにすべて地獄に落とされるつもりですが、これがまさに私の店でデータモデリングとソフトウェアエンジニアリングの責任を分離した理由です。プログラマーがセットの形式で考えることはめったになく、代わりにデータの使用に焦点を当てているようです（3番目の通常の形式、インデックス、またはその他のDBパフォーマンスの問題を維持するのではなく）。プログラマーとしての私たちは、純粋なデータモデリング/アーキテクチャの問題に関する経験不足に基づいて、DBアーキテクチャの決定について、おそらく必要以上に反対する傾向があります。私見、私は、データアーキテクトとモデラーが要件を受け取り、テーブル/プロシージャ/などを構築し、出力の処理を自分に任せることが好きです。

しかし、この設計の実際の理由を知らずに（96以上の異なる数値出力=多数のテーブル列を備えた気象センサーに取り組んでいます）...これは、単に気分を害するようなものです。