0

私はデータベースに不慣れですが、技術を研究していますが、私のDBの最良の計画については明確ではありませんか？

次の列（約65,000行）を持つ「index_table」があります

dbo.index_table
Line
Locality
Route (unique)

次に、次の列を持つ約65,000のテーブルを計画します:(それぞれ約20〜40行）

dbo.table2,3.4....etc
Route 
Place
Name
Stop

私のC＃Webサービスは、index_tableで行と地域の一致を見つけ、結果はルートになります。次に、他のテーブルの一致するすべての行を返す必要があります。基本的に、各テーブル（index_tableを除く）には通過ルート上の停車地が含まれているため、ルート識別子から停車地を見つけています。

これは設計の正しい方法ですか、それともパフォーマンス上の理由から別の方法で設計する必要がありますか。

私は初心者です、優しくしてください:)

4

2 に答える 2

3

65,000のテーブルはまったく必要ないと思います。データベースの正規化を読んで、効率的で組織化されたスキーマを持つことに関する原則を理解する必要があります。65,000のテーブルを実装および管理しようとすると、人生がはるかに難しくなります。（65000 * 20-40）1300000-2600000行を持つ単一のテーブルは、非常に効率的に管理できます。

あなたindex_tableの、あなたが意味するとき、あなたrouteは単一の値を意味しますか？それとも、これrouteには複数の値が含まれますか？

デザインについての私の考えは次のとおりです。

ルート（ルート、ライン、地域）

route_stop（ルート、場所、名前、停止）

  • route_stop.routeの外部キーになりますroute.route
  • サンプルデータがないため、主キーはroute_stop、一意の値を作成する列の複合である可能性があります
于 2012-12-02T15:39:25.750 に答える
1

65,000のルートがあり、それぞれに20〜40の停車地があるため、データがほとんどなく、巨大なテーブルの重みでデータベースが停止するポイントにはほど遠いです。（数千万のストップがあった場合でも、必要に応じてパーティション分割またはシャーディングやその他の手法を使用して、1〜3個のテーブルで問題ありません）。

njkは、ルートと停車地の間で1対多の場合、ルートのテーブルと停車地のテーブル（彼に+1）だけが必要であるという点で正しいです。

ただし、ここで実際に1対多のシナリオがあるとは想像できません。私が知っているすべてのトランジットシステムでは、停車地はルート間で共有されており、多対多のシナリオがあります。ストップテーブルの主キーを導入してstop_idから、ルートとストップをリンクする結合テーブルを作成します。結合テーブルには、ルート内の停車地の位置を示す3番目の列が含まれます。

したがって、リレーショナルデータベースでは、3つのテーブルがあります。

ROUTE: route_id, line, locality
STOP: stop_id, name, place
ROUTE_STOP: route_id, stop_id, position

（余談ですが、NoSQLに興味がある場合、これはMongoDBなどのドキュメントデータベースに慣れるための非常に優れたアプリケーションです。その後、各停車地のリストを使用して、注文するのに位置番号は必要ありません。ルート内で停止します-ところで、私は「優しく」しています:)正しく理解していれば、元の質問には欠けているようです...）

于 2012-12-02T16:00:05.153 に答える