0

テーブル数を減らすためにデータベーススキームを変更することを検討しています。異なるが類似したデータを含むテーブルがいくつかありますが、このままにしておくのがベストプラクティスなのか、それともそれらを組み合わせると複雑になるのではないかと考えています。

たとえば、次の2つのテーブルがあるとします。

Table `status`

`status_id` | `status_text`
---------------------------
1           | Open
2           | Closed
3           | On Hold

Table `type`

`type_id`   | `type_text`
---------------------------
1           | Regular Work
2           | Advanced Work
3           | Warranty Work

これらを次のようなテーブルに組み合わせると有利でしょうか？

Table `text`

`id`        | `type`        | `text`
-------------------------------------------
1           | 1             | Open
2           | 1             | Closed
3           | 1             | On Hold
1           | 2             | Regular Work
2           | 2             | Advanced Work
3           | 2             | Warranty Work

このtype列は、データセットタイプを表すPHP定数に相関します。

私は現在、この正確なスキームのデータを含む6つのテーブルを持っています。それらが非常に類似していて、それぞれが2〜5行しか保持していないことは私を悩ませます。私は本当に上記のようにそれらを組み合わせたいと思っていますが、それから将来的に合併症が発生するのか、それともベストプラクティスを破っているのかはわかりません。

id列が競合し、主キーの候補にはならないことは確かですが、衝突を防ぐための一意のキーになりますtype。これらのテーブルは手動で管理されるため、auto_incrementについては心配していません。

また、これらのテーブルがいくつかのJOINSに関係していることも覚えておいてください。ON句に条件をもう1つ追加する以外に、JOINが複雑になることはないと思います。

これが重複した質問である場合はお詫び申し上げます。データの選択について一般的な質問ではなく、スキームについて質問しているため、調べるのは難しいと思われました。

4

4 に答える 4

4

いいえ、これは問題ありません。適切なデータベース設計/正規化を逆行し、データを不必要に難読化しています。

確かにこれは可能ですが、将来のある時点で後悔するでしょう。「ねえDemonslay335、テキストタイプテーブルのこの作業タイプはどのテキストタイプですか？私のためにそれを入力できますか？タイプタイプタイプタイプ」のような質問が本当に表示されますか？

データをメタタイピングするのと同じように、単語を何度も言うと、それはぎこちないものになります。

于 2013-01-08T22:28:07.107 に答える
1

異なる制約がある場合は、データが「似ている」場合でも、別々のテーブルを使用する必要があります。

たとえば、ルックアップテーブルが分離している場合、さまざまな参照テーブルに対してFOREIGNKEYを非常に自然に定義できます。

すべてを同じテーブルに置くと、同じことを行うのが難しくなります。純粋に宣言的な方法はtype、FKに沿って移行してから、参照テーブルにCHECKを入れて、正しいタイプを確認することです。残念ながら、MySQLはチェックを強制しないため、トリガーまたは（神は禁じられている）アプリケーションロジックを介して正しいタイプを強制する必要があります。

于 2013-01-08T23:13:15.667 に答える
0

長所と短所があり、それはしばしば個人的な好みに帰着します。私は個人的に複数の異なるルックアップテーブルを好みます（偶然に類似したプリミティブ型で構成されているにもかかわらず、それぞれがドメイン内の異なるエンティティ定義に対応しているため）。他の人は、あなたが述べる理由から、単一の「スーパールックアップ」テーブルを好むことがあります。

私がよく見たアプローチの1つは、次のようなものを用意することです。

LookUp
----------
ID
LookUpTypeID
Value
DisplayText
etc.

LookUpType
----------
ID
Name

これにより、ルックアップ値を単一の構造に編成するためのかなり簡単な方法が提供されます。また、タイプを分離して異種のテーブルを「模倣」したい場合（たとえば、私のような開発者がチームに参加して多くの騒ぎを起こした場合）、タイプに基づいてビューを作成し、使用することができます。クエリ内のもの。

複数の小さなテーブルに本質的に問題はありません。それらに含まれるデータが本当に異なる何かを意味する場合、私はそれを分離する必要があると主張します。ドメイン内のエンティティの概念的な意味は、それらが構成されているデータ型よりもはるかに重要です。

また、複数の小さなテーブルはデータベースエンジンにほとんど違いをもたらしません。それはかなり最適化されています、あなたはテーブルを組み合わせることによってそれを何の恩恵もしていません。実際、これを行うと、時間の経過とともにクエリが少し鈍くなることがあります。データベースから照会されるデータの意味は、テーブル内の実装の詳細によって曇り始めます。ビューを追加してデータを再び論理的に分離することでこれを軽減できますが、それを行う必要がある場合は、そもそもなぜそれを組み合わせるのですか？

于 2013-01-08T22:28:30.880 に答える
0

テーブルを1つのテーブルに結合する理由はわかりません。

私が検討することの1つは、列挙型列を使用することです。を参照する外部キーである列がある場合はstatus、代わりにそれらを列挙型にします。その後、テーブルを完全に省くことができます。これにより、スキーマが単純になります。しかし、それにはいくつかの弱点があります（いくつかはそれを悪と呼ぶところまで行きます）; たとえば、複数の場所で同じ列挙を使用する場合、すべての定義が同じであるという保証はなく、データベースが進化するにつれて、それらが同期しなくなるリスクがあります。それでも、私たちはスキーマでそれらをかなり頻繁に使用しており、それによる苦痛は実際には感じていません。

于 2013-01-08T23:53:24.903 に答える