-1

私は、研究室の人々が中央データベースを介して特定の材料を注文できるようにする内部サイトを開発しているので、物事を管理しやすくしています。

人が注文し（1つのアイテム、またはそれぞれ数量が異なる複数のアイテムなど）、データベースにログインします。ただし、データベースの設定方法を決定するときは、次の2つのオプションが表示されます。

オプション1は、すべてのデータを1つのテーブルに配置します。 

|   Salt   |    Name    |     Email     |   Product ID   | Quantity |Sent|
==========================================================================
|0000000001|John Doe    |john.doe@au.dk |175463          |25        |1   |
--------------------------------------------------------------------------
|0000000001|John Doe    |john.doe@au.dk |300146          |169       |1   |
--------------------------------------------------------------------------
|0000000001|John Doe    |john.doe@au.dk |855457          |5         |1   |
--------------------------------------------------------------------------
|0000000001|John Doe    |john.doe@au.dk |290142          |13        |1   |
--------------------------------------------------------------------------
|0000000002|Jane Doe    |jane.doe@au.dk |173755          |3         |0   |
--------------------------------------------------------------------------
|0000000002|Jane Doe    |jane.doe@au.dk |256984          |39        |0   |
--------------------------------------------------------------------------

多くの行が複製され、読み取り/書き込み/更新の速度が向上し、ストレージスペースが大幅に増加します。しかし、すべてが1つの場所にあるため、より簡単です。

オプション2：

2つのテーブル。注文を記録する（そして一意のソルトを割り当てる）もの。もう1つは注文の詳細（アイテム）をログに記録し、ソルトはログに記録されます。一部の注文には複数のアイテムが含まれている可能性があるため、2番目の表ではソルトは一意ではありません。2つのデータベースは、のようにリンクされており、注文を引き出しようとすると、すべてのアイテムがその順序で配置され、ソルトを検索するだけです。

表1：

|   Salt   |    Name    |     Email     |Sent|
==============================================
|0000000001|John Doe    |john.doe@au.dk |1   |
----------------------------------------------
|0000000002|Jane Doe    |jane.doe@au.dk |0   |
----------------------------------------------

表2：

|   Salt   |   Product ID   | Quantity |
========================================
|0000000001|175463          |25        |
----------------------------------------
|0000000001|300146          |169       |
----------------------------------------
|0000000001|855457          |5         |
----------------------------------------
|0000000001|290142          |13        |
----------------------------------------
|0000000002|173755          |3         |
----------------------------------------
|0000000002|256984          |39        |
----------------------------------------

2番目のオプションの利点は、各行の冗長な情報が少ないことです。逆に、最初のオプションの利点は、2つと比較して、維持する必要のあるテーブルが1つしかないことです。

最初に処理しやすい単一のテーブルを使用する必要がありますか、それともデータベースの正規化のベストプラクティスに準拠するために複数のテーブルを使用する必要がありますか？どちらに進むかを決めるために使用するプロセスは何ですか？

4

1 に答える 1

1

私は、1人のプログラマーのペットプロジェクトが10年の間に（私がそこにいる前に）数万行のコードにまで拡大した仕事で働いてきました。太陽の下ですべてを行ったプログラムは、混乱しています。物事を速くやりたいと思っていて、時代を超越したコーディングの原則に従わなかったプログラマーのために、それは混乱するようになりました。

だから、混乱の具体例として。200〜300列のデータベーステーブルがあります。常に何か問題があり、それは巨大なプロジェクトになるため、より直感的な構造に分解することはできません。あなたは「簡単だからすべてを一か所に詰め込む」という誤謬を合理化することによって雪玉の転がりを始めています。

データベースは常に、カプセル化され、正規化され、効率的で直感的なものにしてください。今はもっと難しいですが、あなたのコードに取り組まなければならない将来のプログラマーはあなたに感謝するでしょう。また、些細なプロジェクトであっても、コードに混乱が生じているのを人々が見た場合、今後35年間で、小惑星帯から資源を採掘する宇宙船でクラフトを練習することはできません。もっと重要なことを任せたいので、美しい仕事をしてください。

于 2013-10-11T13:22:27.097 に答える