0

ほとんどの開発者と同様に、私は常に最適なコードとデータベース スキーマを作成するよう努めています。

ただし、作成したいデータベーススキーマを設計しすぎていると感じています。

短時間で多くのユーザーを保持する Web アプリがあります。ユーザーは、顧客、サプライヤー、システム ユーザーの形をしています。急成長が期待できる業界です。

以前のスキーマでは、これらのユーザーを異なるテーブルに分けていました。

ただし、私は現在、PEOPLE という名前のテーブルを 1 つ持つというルートをたどることを考えています。

これらのテーブルがあります:

人物、連絡先、住居

それらは、ピボットテーブル、つまり PivotContacts PivotResidences を介して関連付けられています。

私の質問は、これは良い/悪いデザインと見なされますか? 私は考えすぎて、単純なセットアップを設計しすぎているのでしょうか。

テーブル People は指数関数的に成長し、大量のデータを保持します - そして他のテーブルはそれに関連します。

私は本当に意見を歓迎します。

デザインは 100,000 レコードまで拡張でき、適度な速度を維持できますか? * 最初は 1000 レコードから開始し、1 年で約 100,000 レコードに増加する可能性があります。

4

2 に答える 2

1

ログインでき、トレースされる可能性があるユーザー (最後のログイン、パスワードの再試行の失敗) の場合、小さなテーブルと、書き込み用の別のテーブル (データの読み取りと書き込みの区別) を用意するのが最適です。

一般に、人がいるテーブルには、膨大な数のフィールドが集まる傾向があります。さまざまなテーブルに保持されている機能の違いにより、データが整頓された状態に保たれます。サプライヤー テーブルでのインデックス作成は、サプライヤー データへの変更と同様に、より適切であり、おそらくより最適です。SQL JOIN は扱いやすく、SQL ビューで実行できます。

したがって、薄いベース テーブル People と、1:1 テーブルの SupplierPeople、SystemUsingPeople などを使用します。そして、どのような変更が発生するかを検討してください。つまり、テーブルが更新、挿入、読み取られる頻度です。

また、フィールドを追加して、データベース スキームを変更する必要があることも考慮してください。

于 2013-04-25T08:58:48.853 に答える
0

ソリューションのスケーラビリティのみを気にしている場合、100K レコードは、いくつかの (重要な) 仮定の下では特に大きな数ではありません。

最新のデータベース ソフトウェア (PHP の専門家であると言うように、MySQL を使用することになると思います) は、適切に設計されたテーブル レイアウトがあれば、何百万ものレコードを含むデータベースを簡単に処理できます。インデックスを使用します。

あなたのデザイン - 「人」を「連絡先」および「住居」にリンクすることで、主キー/外部キーを使用して参加できます。要件に合わせて簡単に拡張できます。

ただし、実行する可能性のあるクエリを検討する価値はあります。名前、住所、都市、または最終連絡日などで「人」を検索できる必要があると思います。フリーテキスト検索が必要な場合があることをお勧めします-多数のレコードに到達すると、使用where name like '%Jones%'が遅くなる可能性があります。

また、アーカイブ/履歴戦略を検討することもできます-誰かの住居の履歴を保存する必要がありますか (注文時に住んでいた場所を見つけることができます)?

于 2013-04-25T09:53:21.817 に答える