0

私は非常に小さなデータベースをマッピングしていて、優れた設計手法についていくつかの設計上の質問があります。たとえば、レストランのテーブルがあり、レストランに住所と営業時間と特別な日（MTuWThF）があるとします。

  1. レストランの住所は1つだけです。関連するすべてのアドレスフィールド（Street 1、Street 2、City、State、ZIP）をRestaurantテーブルに入れたいと思っていますが、それを独自のテーブルに分割すると、ドメイン内にAddressクラスを作成できると思います。オブジェクトと、後でアドレスの実行方法を変更したい場合は、簡単になる可能性があります。私は通常、1：1テーブルを悪い習慣だと思っていました...

  2. オープンタイムは、レストランがいつオープンするかをHH：MMで表したものです。日付部分が無駄になるため、完全なDateTimeは必要ありません。では、varcharはこれを表す最良の方法ですか？

  3. 特別な日（月曜日、火曜日など）があります。スキーマにも保存したいと思います。この日をvarcharとして保存するのは理にかなっていますか、それとも日曜日（1）、月曜日（2）などの参照テーブル（列挙型のようなもの）を作成することをお勧めしますか？特別な日が当たる日を格納するためにintを使用しますか？

    **DayOfWeek**
Id (int)
Day (varchar)

**Service**
Id (int)
RestaurantId (int)
DayOfWeekId (int)
...

みんなありがとう！

4

2 に答える 2

0

あなたが求めていることの多くは、それがあなたのニーズに最適であるとあなたが考える方法に要約されます。うまくいけば、私が以下に言うことのいくつかが役立つでしょう。

1対1のテーブルは必ずしも悪いわけではなく、実際、データを分割して取得をより効率的にするために使用されることもあります。たとえば、頻繁に使用するフィールドが10個あり、あまり使用しない比較的大きいフィールドが25個ある場合は、データベースエンジンが使用しないように、25個を別の1対1のテーブルに配置できます。あなたがいつも使っている10のフィールドを引っ掛けているとき、彼らと一緒にいじくり回さなければなりません。

あなたの場合、私はどちらにでも行くことができます。経験豊富な開発者でない限り、住所フィールドをレストランのテーブルに配置することをお勧めします。あなたはそれを考えすぎたくない。派手になりすぎようとすると、決して起こらないかもしれない何かに多くの時間と労力を浪費するだけになるでしょう。さらに、後で住所テーブルのデータを変更することにした場合、正直なところ、レストランのテーブルで直接実行するよりも、住所テーブルでいくつかのALTERTABLEコマンドを実行する方が簡単ではありません。つまり、後で変更することがわかっている場合を除いて、シンプルに保ちます。

時間に関しては、一部のデータベースシステムは実際にはTIMEタイプ（日付付き）をサポートしています。たとえば、これはMySQLのドキュメントです。もう1つのオプションは、標準のDATETIMEを使用することですが、参照ポイントとして特定の日付を使用します。たとえば、1970年1月1日です。したがって、午後3時30分に保存する場合は、「1970-01-0115:30:00」として保存します。時間部分だけを表示したいバックエンドで任意のフォーマットを実行できます。これの利点の1つは、最終的にこれらの時間を任意の種類の計算で使用する場合、VARCHARとしてよりもDATETIMEとして保存する方がはるかに簡単なことです。たとえば、特定の日にレストランが開いている時間を知りたい場合は、次のように使用できます。

SELECT `closetime` - `opentime` AS "openhours" FROM `restaurants`;

曜日の保存については、正直、TINYINTにして、1（日曜日）から7（土曜日）まで保存します。MySQLには、曜日として1から7を返す組み込み関数があり、ほとんどのデータベースは同じであると思います。以下のようなクエリでは、特定の日付が「特別な」日であるかどうかを判断するのがはるかに簡単になります。

SELECT * FROM `restaurants` where DAYOFWEEK(?) = `special_day`

ほとんどのスクリプト言語では、それを準備されたクエリとしてコンパイルでき、日付を非常に効率的にパイプすることができます。

うまくいけば、これはあなたにいくつかの考慮事項を助け、与えるでしょう。あなたのプロジェクトで頑張ってください、特にあなたがタイムスパンなどに入り始めたとき、日付と時間は対処するのに本当に厄介になる可能性があります。

于 2012-05-30T02:58:21.883 に答える
0

私は非常に小さなデータベースをマッピングしています

したがって、データベース全体がキャッシュに収まる可能性が高いため、I / Oを向上させるためだけにテーブルを垂直方向に分割する理由はほとんどありません。つまり、I/Oについて話すことはありません。

1 .. ..

データベースは、クライアントアプリケーションのコードでデータがどのように表されるかではなく、データを考慮する必要があります。別のテーブルにない場合でも、コード内で許容できる方法でアドレスを操作できると確信しています。少なくとも、ORMが生成したものはすべて手動でラップできます（または、そもそもORMを使用しないでください;））。

2 .. ..

ええと、1日に24 * 60 = 1440分あり、これはに快適に収まりsmallintます。

時間のみ（または分のみ）でクエリを実行する場合は、2つのtinyintフィールドに分けてください。

3 .. ..

別のテーブルと参照整合性を使用します。このようにして、1つの場所で特別な日を変更でき、接続されているすべての行に自動的に「伝播」します。また、必要に応じて、複数の特別な日を過ごすことができます。

OTOH、常に1つの特別な日があることがわかっている場合は、その日だけを含む1つの行を持つ「シングルトン」テーブルを作成できます。この場合、実際にはFKは必要ありません。日数が少ないため（7）、CHECK制約のみで有効な値を制限することは実用的な範囲内です。

于 2012-05-30T12:45:28.713 に答える