3

「独自のフォームを作成する」スタイルの Web サイト (例: Wufoo ) 用のスケーラブルで柔軟かつ高速なデータベース設計を探しています。

ルール:

  1. ユーザーが作成できるフォームは 1 つだけです
  2. ユーザーは独自のフィールドを作成するか、「標準」フィールドから選択できます
  3. ユーザーの 1 フォームには、ユーザーが必要な数のフィールドがあります
  4. 値は別の値の兄弟になることができます。たとえば、写真の値は、兄弟の値として名前、場所、幅、高さを持つことができます

特別ルール:

  1. ユーザーは 1 日に最大 5 回フォームを送信できます
  2. 値の日付は重要です
  3. 値をレポートする柔軟性 (単一ユーザー、すべてのユーザー、1 つのフィールド、複数のフィールド) は非常に重要です。データの視覚化 (ほとんどの場合、すべてのユーザーの 2009 年 7 月のすべての写真など、時系列に基づいています)。

テーブル「ユーザー」

イド

テーブル "field_user" - フィールドをユーザー フォームに割り当てます

フィッド

イド

weight - int - ユーザーフォームのフィールドの順序付けに使用

テーブル「フィールド」

フィッド

Creator_uid - int - フィールド「作成者」

ラベル - varchar - 例: 電子メール

value_type - varchar - 「値」テーブルのどのフィールドが入力されるかを決定するために使用されます (たとえば、「int」の場合、このフィールドの値はデータを values.type_int フィールドに送信します - 他のすべての .type_x フィールドは NULL になります) .

field_type - varchar - 例: 'email' - 検証ルールなどの特別な条件に使用

表の「値」

ビデオ

parent_vid

フィッド

イド

日付 - 日付

date_group - int - 値 1 ～ 5 (ユーザーは 1 日に最大 5 つのフォームを送信できます)

type_varchar - varchar

type_text - テキスト

type_int - int

type_float - フロート

type_bool - ブール

type_date - 日付

type_timestamp - タイムスタンプ

このアプローチは、「値」テーブルのレコードが NULL を含む他の .type_x フィールドを持つ 1 つのデータしか持たないことを意味することを理解しています... しかし、私の理解では、この設計は「最速」のソリューションになります (クエリが少なく、結合が少ない)テーブル）

4

4 に答える 4

5

昨日のOSCONで、Josh Berkusは DB 設計に関する優れたチュートリアルを行いました。彼はそのかなりの部分を容赦なくそのような「EAV」il テーブルに引き裂くことに費やしました。OSCON サイトで彼のスライドをすぐに見つけることができるはずです。最終的にはオンラインで彼のチュートリアル全体の音声録音を見つけることができます (後者にはおそらくしばらく時間がかかります)。

属性ごとに結合（テーブルの複数のインスタンス、valuesフェッチまたは更新する属性ごとに1つ）が必要になるため、「テーブルの結合が少ない」という意味がわかりません。同じテーブルの多くのインスタンスを結合することは、特に高速な操作ではありません。また、設計により、インデックスはほとんど実行不可能で使用できなくなります。

少なくともマイナーな改善として、属性の値にタイプごとに個別のテーブルを使用します (その場合、いくつかのインデックス作成が適用される可能性がありますが、MySQL ではテーブルごとのクエリごとに 1 つのインデックスに制限されているため、多少疑わしいこともあります)。

于 2009-07-21T15:34:06.140 に答える
2

CouchDBのようなスキーマのないデータベースを実際に調べる必要があります。このような問題は、まさにこれらのタイプの DB が解決したい問題です。

于 2009-07-21T15:46:50.170 に答える
0

ご存知のように、テーブルの作成、変更、列の追加などは、多くの最新の rdbms 実装で実行時に実行できる操作です。なぜ EAVil なのか? 特に動的SQLを使用している場合。

気弱な人向けではありません。データベースに 70,000 のテーブルを作成した Boeing での実装を思い出します。

明らかに、動的テーブルの作成には落とし穴がありますが、EAV テーブルにも存在します。同じ事実を表す同じキーの 2 つの属性のようなもの。または、推移的な依存関係やその他の正規化の落とし穴。では、少なくとも RDBMS の機能を活用してみませんか?

于 2009-07-22T21:32:10.770 に答える
0

私はジョン・オーウェンに同意します。

スキーマからクエリを動的に作成することは、EVA テーブルにクエリを実行することに比べてわずかな費用で済みます。特にテーブルが大きい場合。

通常、テーブルの列は「インターフェース」と見なされます。動的に変化するインターフェイスに依存する設計は、通常は良くありませんが、EAV データは多くのオプションがない特殊なケースです。時間がかかり直感的でないクエリか動的スキーマのどちらかを選択する必要があります。

于 2010-11-01T19:17:59.610 に答える