15

バックエンドに MySQL データベースを使用する現在取り組んでいる Web アプリケーションがあり、先に進む前に自分の状況に何が適しているかを知る必要があります。

簡単に言えば、このアプリケーションでは、ユーザーは任意の数値フィールドを使用して独自のフォームを作成することができ (ユーザーが決定します)、現在、すべてを外部キーでリンクされた 2 つのテーブルに格納しています。私の友人は、物事を「簡単/高速」に保つために、各ユーザーのフォームをフラットテーブルに変換して、ユーザーからのデータのクエリが高速に保たれるようにすることを提案しています (大幅な成長の場合)。

外部キー (インデックスなど) を持つリレーショナル テーブルにすべてをプールして、データベースを正規化する必要がありますか?それとも、ユーザーが作成する新しいフォームごとにフラット テーブルを構築する必要がありますか?

明らかに、フラット テーブルを作成する利点のいくつかは、データの分離 (セキュリティ) であり、クエリの速度が低下します。しかし、真剣に、これからどれだけの利益が得られるでしょうか? 10000 個のテーブルを常に削除、変更、および追加することは本当に望んでいませんが、それが私よりも優れている場合は... 入力が必要です。

ありがとうございました

4

7 に答える 7

22

経験則。正規化から非正規化への移行は、その逆よりも簡単です。

合理的なレベルのデータベースの正規化から始めます (合理的とは、読みやすく、保守可能で、効率的ですが、時期尚早に最適化されていないことを意味します)。成長するにつれてパフォーマンスの問題に遭遇した場合は、非正規化によってパフォーマンスが向上する方法を検討するオプションがあります。

于 2010-12-01T19:05:37.960 に答える
6

データを正規化してください。適切にインデックスを作成すると、パフォーマンスの問題が長期間発生することはありません。

セキュリティについて: フラットなアプローチでは、多くの create/drop table、a​​lter table などのステートメントを記述する必要があります。つまり、より多くのコードとより多くの障害点が必要になります。

フラット ファイルを使用する唯一の理由は、ユーザーが DB に直接接続できる場合です (行レベルのセキュリティを引き続き使用できます)。しかし、その場合、実際には phpmyadmin のバリアントを再実装しています。

于 2010-12-01T19:20:17.160 に答える
3

...in this application users will be able to construct their own forms with any number fields...

Yikes! Then how could you possibly do any sort of normalization when the users are, in essense, making the database decisions for you.

I think you either need to manage it step by step or let your freak flag fly and just keeping buying hardware to keep up with the thrashing you're going to get when the users really start to get into it....Case in point, look what happens when users start to understand how to make new forms and views in SharePoint...CRIKY!! Talk about scope creep!!

于 2010-12-01T19:11:18.950 に答える
2

実行時にスキーマを変更することは、ほとんど良い考えではありません。考慮したいのは、EAV (Entity-Attribute-Value) モデルです。

ウィキペディアには、長所と短所、および実装の詳細に関する非常に優れた情報があります。EAV は可能な限り避けるべきですが、各フォームの列数が不明な状況では、EAV を検討する価値があります。

于 2010-12-01T19:06:12.057 に答える
1

データを正規化してください。適切なインデックスがあれば、システムは高速のままになります。

本当に高速化したい場合は、スキーマを bigDB /couchDB などのキー値データベースの 1 つに切り替えます。これは完全に非正規化されており、非常に高速です。

于 2010-12-01T19:06:35.383 に答える
1

これを処理する方法は、次のような正規化された拡張可能な「プロパティ」テーブルを使用することです。

Table: FormProperty
 id: pk
 form_id: fk(Form)
 key: varchar(128)
 value: varchar(2048)

上記は一例ですが、私はこのパターンを多くの場合に使用しており、かなりうまくいく傾向があります。唯一の本当の「落とし穴」は、値を文字列/varcharとしてシリアル化し、必要に応じて逆シリアル化する必要があることです。そのため、クライアントの責任が少し追加されます。

于 2010-12-01T19:18:40.450 に答える
0

正規化 == 高速な検索、インデックスの維持が容易、トランザクションの挿入が遅い (複数の行で)

非正規化 == 高速挿入。通常、これは挿入が多い場合に使用されます (時系列データを収集して記録するデータ ウェアハウス)。

于 2010-12-01T19:50:20.920 に答える