database - データベースを正規化するよう誰かを説得する方法は?

Question

だから私は、私が制御できないデータベースと対話するphp Webサイトをコーディングしている職場でこのプロジェクトに取り組んできました。データベースは、私よりも長い間会社に勤務している同僚によって「設計」されました。したがって、最終的な決定は彼らの決定に任されています。

このプロジェクトに初めて参加したとき、同僚のところに行き、データベース スキーマに欠陥があるようだと説明しました。データベースを正規化してデータの整合性の問題を確実にし、ディスク領域を節約することの重要性と、プログラマー (私) の仕事を容易にすることを説明しました。挿入、削除、および更新の異常が現在の設計でどのように発生するかの例も示しました。それにもかかわらず、同僚は、プロジェクトのデータベースを過度に複雑にしたくないので、期間を変更しないと説明してくれました。

そのため、プロジェクトを開始して数か月が経ちましたが、2 つのテーブルを結合して、互いに 1 対 1 の関係を持つ属性に値を挿入する必要があるたびに、頭を悩ませています。(したがって、属性は単にメイン リレーションの属性である必要があります。) データベースは見栄えが悪く、データベースを使用するフロント エンドをプログラムしたので、数年後にこれが戻ってくるのではないかと心配しています。

「上司」の同僚にデータベースを正しく設計するよう説得する方法について、誰か提案はありますか? または、私が何の役にも立たなかったデザインのために何年も愛用されないようにする方法についての提案はありますか? 今後、このようなプロジェクトに取り組むことを拒否する必要がありますか? 私のコードにコメントを残して、データベースは私がやったことではないということですか?

ありがとう。

編集：コメントへの追加情報...

データベースの非正規化が速度向上に役立つことはわかっているので、これを見落としているわけではありません。この戦術について聞いたことがない読者のために、例を示します。多くの場合、データベース設計者は、ユーザーの番地、都市、州、および郵便番号をリストする住所関係を持っています。郵便番号が都市と州を決定することは誰もが知っているため、郵便番号を都市と州にインデックス付けするテーブルを構成します。多くの場合、データベース設計者は 2 つのテーブルを結合し、ユーザーのアドレスに対するすべてのクエリでアドレス テーブルから zip テーブルへの結合が必要になることを予測して非正規化します。これにより、最終的にクエリ処理が高速化され、データベース設計の一部を非正規化する正当な理由になります。

ここに詳細を入力するために、データベースはツアー リクエスト システム用に設計されているため、内部のデータは訪問者情報、日付などに関連しています。現在のデータベースが使用するスキーマは、最初から最後まで予測できません。変数の命名パターン (例: num_of_visitors、arrivalMethod など) の最も単純な矛盾から、単一の状態の 1 対 1 の属性に対して定義された別個の関係を持つことまで。例: statusID はツアー リクエストのステータスを表します。有効な状態は、可能な状態 (承認済み、拒否、保留中、キャンセル済み) のグループから選択された 1 つのみです。何らかの理由で、データベースには以下を含むステータス テーブルがあります: tour_id(Primaryツアー関係のキー)、statusID. これにより、ツアー リクエストごとに複数の状態を定義できます。これは、設計上、ツアー リクエストが常に 1 つの状態にある必要があるためです。

Answer 1

私の経験上、この種の状況では、残念ながら勝てない戦いになることがよくあります。デザインから距離を置くためにできることは次のとおりです。

• 実際のデータベース設計を可能な限り抽象化するコードにデータ アクセス レイヤーを実装します。このようにして、コードをより適切な形式で構造化することができ、悪いデータベース設計を使用したり、そのせいで非難されたりすることから効果的に「距離を置く」ことができます。
• DB にビューを作成して、より論理的な形式でデータにアクセスする
• うまくいけば、機会があれば、テーブル/コードに小さなリファクタリングを行います

コードに軽蔑的なコメントは入れません。データ アクセス レイヤーでは、特定の設計を抽象化している理由と、それを別の方法で設計する方法を説明する、客観的/攻撃的ではないコメントを入れることができます。

状況が本当に悪く、誰もあなたをサポートしてくれない場合は、別の仕事を探す時期かもしれません。

Answer 2

仕事を変える。

編集：

短い答えは、私が冗談を言っているからでも、質問を真剣に受け止めていないからでもありません。私は以前にそのような状況にあったことがあります。悪いデータベースは問題ではありません。問題は盲目または無知な管理です。つまり、重要な技術的決定が無能な人々によって行われていることを彼らが知らない、または気にしない場合、事態はさらに悪化します。沼地に足を踏み入れるようなものです。

新しい仕事を探すことを真剣に検討してください。開発者にとって本当に素晴らしい職場があります。これはそうではありません。あなたは時間を無駄にしています。

Answer 3

データベース設計者にデータベースを作り直すように説得できない場合があります。特に、現在存在するデータベースに対して作成されたコードがすでに多数ある場合はそうです。

ただし、適切に設計されたデータベースと不十分に設計されたデータベースの違いを説明するために、語彙を拡張する必要があります。正規化するだけでは修正できない、悪いデータベース設計がたくさんあります。あなたが与える1つの例は、良いデザインが同じテーブルにデータを置く場合、別々のテーブルからのデータを結合しなければならないので、あなたの髪を引き裂くことです。

構成されたままになっているはずのテーブルを分解することは、通常、正規化の失敗ではありません。正規化のほとんどすべての失敗は、分解されるべきである構成されたテーブルをもたらします。更新の異常について彼女を指導することについてのあなたのコメントから、私が通常の形式についてあなたに教えることができるかもしれないことは何でもあなたはすでに知っていると確信しています。

「ハイパーノーマライズ」と呼ばれることもある、悪い理由でテーブルを分解することは、設計上の欠陥の別のフレーバーです。この欠陥から生じるプログラミングの問題は、正規化不足から生じる問題とは大きく異なります。

同じデータベースで動作するコードを開発するプログラマーは他に何人いますか？残りのプログラマーはデザインについてどのように感じていますか？彼らが本当に幸せなら、それは物事を変える可能性をさらに減らします。それらがすべて形が崩れている場合は、数字の強さを見つけることでデザイナーを説得​​できるかもしれません。私は知っている、私は知っている、それは政治だ、そして私はあなたが政治を憎むに違いない。

私がデータベースのプログラミングと設計についてプログラマーに教えていた頃、学生はデータベースの仕事になぜそんなに多くの政治があったのかとよく尋ねました。私は最終的に簡単な答えを思いついた：

データベースが広く使用されている場合、データ共有が発生します。それは知識の共有を意味します。知識は力である。権力が共有されているとき、政治が起こります。

Answer 4

非正規化によって引き起こされたバグを見つけます。データベースに適切な制約がない場合 (そして、状況によってはそうではないと私は推測しています)、そのようなバグが存在します。私はそれにお金を入れます。バグトラッカーを使用している場合は、そこを見てください。そうでない場合は、自分で解決してください。いずれにせよ、そのようなバグが引き起こす可能性のある損害と、クリーンアップにかかる費用を示すことができます。

Answer 5

多くの場合、開発者は、ばかげたことを要求するクライアントと協力する必要があるか、設計が非常に悪いレガシーコードを維持/操作する必要があります。もちろん、データベースをどのように設計すべきかを同僚に納得させたり教育したりする必要がありますが、主な努力は最高品質のソース コードを提供することです。多くの場合、そのような状況に対処する必要があります。

データベースの周りにレイヤーを作成するために、既に与えられたアドバイスに従うことをお勧めします。「db テーブル 1 と 2 が正規化されていないため、この複雑なことを行う」などのコメントを入力します。コメントに批判を入れないでください。それらを厳密に技術的なものにしてください。ときどき、データベースの設計について同僚やマネージャーと話し合ってください。関連本を購入して、みんなが見られる場所に置いてください。誰かに頼まれたら貸してあげましょう。それでも、あなたの主な努力は良いコードを書くことです。

Answer 6

このデータベースに対して実行する必要がある操作を指定し、それらをデータベース内のストアド プロシージャとして実装することを彼女に提案できますか? ...間違いなく、問題をその原因となった人に置きます。

Answer 7

最も積極的な方法は、同僚と協力して、彼らの考え方を進化させ、教育することです。おそらく、過去に犯した過ちについて話し合うことは、簡単なアイスブレーカーになり、設計が不十分なシステムの意味を彼/彼女に示すことができます.

過去の悪い経験があまりない場合は、特定のタスク/欠陥が完了するまでにかかる時間 (時間またはお金) を記録することをお勧めします。その後、統計を作成できます。すべての管理者はグラフを気に入っています。これにより、機能の追加や欠陥の解決に必要な時間がどのように増加したかを示すことができれば幸いです。

お役に立てれば。

Answer 8

設計が不十分なデータベースをレイヤーの背後に隠そうとすることは「ハック」にすぎず、IMO はプラン B である必要があります。プラン A の場合、より高いレベルに「エスカレート」しようとします。

As you described, you have no authority to influence the person messing the database. I would then go to the architect (assuming there is one) or to the project manager if there is no architect.

It is very important to sustain your arguments with well documented facts regarding the impact the bad design already has on the system you're building. Other facts could be well known issues for bad designed database from the specialized db communities.

I don't have enough information about your situation, but this is what I usually try to do when confronted with customers that insist on a poorly designed technical solution.

Answer 9

地下室に連れて行ってください。大きなソファを運ぶか、小さな椅子4脚を運ぶかを選択してください:)

Answer 10

彼女がデータベースを過度に複雑にしたくないと言ったのは、データベースの正規化について知らないか、その能力がないことを意味していたのかもしれません。その場合、1 つの方法は、正規化の利点を彼女に納得させ、さらにデータベースの正規化を研究するように彼女を送ることです。正規化する理由の 1 つは、データベースを作成することだけがデータベースの唯一の要件ではないということです。データベースは、データ ストレージとして使用されるため存在します。また、データは何に保存されますか? アプリケーション ソフトウェア。したがって、データベースの作成者はソフトウェア開発者に敬意を払い、データベースを正規化する必要があります。そうでなければ、それは本当に厄介な状況になるでしょう。物事を簡単にするために、最初にいくつかの単純な正規化操作を示して、それを使い始めることができます。

Answer 11

上級管理職にこの質問を見せてください。それは、何らかの形での正規化がデータベースの単なる「複雑化」ではなく、有能な開発者の圧倒的多数が基本的であると考える標準的な手順であることを彼らに示します。

Answer 12

この質問は、問題のドメインに関係なく、あらゆる設計と実装を含むように言い換えることができます。

このような状況に陥ると、フラストレーションの大きな原因になります。幸いなことに、私はこれらに数回しか触れておらず、影響を受けた SW の部分をほとんど回避することができました。または、より健全なデータベース レイアウトを使用できる中間層を構築します。

シニア デザイナーと管理者が気にしない/理解しない場合、通常、やるべきことはあまりありません。しばらく前からある sw に変更が必要な場合はいつでも同じです。最初にシステムを設計した人に変更を承認してもらうことは、あなたが上司であり、問​​題を「強制」できない限り、さまざまな心理的理由からしばしば不可能です。それでも、場合によっては実行できない場合があります (sw にあまりにも多くの変更が必要になる可能性があります)。

ただし、パフォーマンスなどの特定の問題がある場合は、1 つの可能性があります。より優れたデータベース設計がこれらの問題を解決することを実証できれば、いくらか前進することができます。