2

私は漫画本のデータベースプロジェクトに取り組んでおり、特定の漫画の問題にさまざまな場所を含めることができる必要があります。私が取り組まなければならないいくつかの問題があります：

  • 場所は他の場所の中にあることが多いです（「デイリーバグルビル」は「39番街と2番街の角」にあり、「ニューヨーク市」は「ニューヨーク」にあります）。
  • 場所の階層はかなり標準的ですが（Universe-> Dimension-> Galaxy-> System-> Planet-> Continent-> Country-> State-> City-> Street-> Building-> Room）、すべての親の場所ではありません必然的にすべての場所で知られています（たとえば、コミックには、アフリカの名前のない国の名前の付いた建物が含まれる場合があります）。
  • その素敵な階層に収まらないが、ある時点で分岐する場所がいくつかあります（たとえば、「サヴェッジランド」は南極の巨大なジャングルであるため、その親は大陸ですが、国ではありません） 。

私の主な目標は、任意の場所の検索を実行し、その場所またはその場所内の任意の場所にあるすべての問題を取得できるようにすることです。2番目の目標は、アプリケーションの管理側で完全な場所をオートコンプリートできるようにすることです（つまり、問題について新しい建物を入力し、それがニューヨーク市にあることを指定すると、すべての「ニューヨーク市」がプルされます。 "インスタンス-はい、データベースに複数の：P-があり、Earth-616またはEarth-1610にあるものを選択できます。または、別の親の場所に新しいニューヨーク市を追加することもできます） 。私ができるすべてのフロントエンドのことと、時が来たときに理解することは、現時点でデータベースのセットアップがわからないだけです。

どんな助けでもいただければ幸いです！

アップデート：

数人の仲間との多くのブレインストーミングの後、私は提案されたネストされたモデルよりも少し単純な解決策を思いついたと思います。

ロケーションテーブルは次のようになります。

  • ID
  • 名前
  • タイプ（「その他」オプションを含む、前述のカテゴリの列挙型リスト）
  • Uni_ID（親ユニバースのID、該当しない場合はnull）
  • Dim_ID（親ディメンションのID、該当しない場合はnull）
  • Gal_ID（親GalaxyのID、該当しない場合はnull）

...すべてのカテゴリでなど...

  • Bui_ID（親ビルのID、該当しない場合はnull）

したがって、フィールドはたくさんありますが、検索とオートコンプリートは非常に簡単に機能します。任意の場所のすべての親がその行にあり、任意の場所のすべての子を1つのクエリで見つけることができます。新しい場所にタイプが定義されるとすぐに、オートコンプリートが簡単に機能します。この時点では、私が見たことのないこの設定の問題を誰かが指摘できない限り、ネストされたモデルではなく、このアプローチに傾倒しています。

4

2 に答える 2

1

階層データの場合、私は常に、親->子（隣接）モデルよりも入れ子集合モデルを使用することを好みます。良い説明とクエリの例については、こちらをご覧ください。これはより複雑なデータモデルですが、データのクエリと検索がはるかに簡単になります。

于 2012-06-01T17:08:10.380 に答える
0

入れ子集合モデルについて@KingIsaacが以前にリンクしたものが本当に好きです。リンクが言ったことに関して私が持っている唯一の議論はスケーラビリティです。lftとrgtの境界を定義する場合は、要素の数を知る必要があります。または、任意に大きな数を設定して、到達しないことを期待する必要があります。このデータベースの大きさやエントリの数はわかりませんが、インデックスの再作成などを必要としないモデルを実装するのは良いことです。これが私の修正版です

create table #locations (id varchar(100),
                         name varchar(300),
                         descriptn varchar(500),
                         depthLevelId int)

create table #depthLevel(id int,
                         levelName varchar(300))

                     ***Id level structuring*** 

                            10--level 1
              100                               101-- level 2           
     1000            1001               1010             1011       --level 3
 10000   10001   10010   10011     10100    10101    10110    10111     --level 4

基本的に、これは非常に単純なクエリになります。重要な部分は、子IDが、親IDとそれに与えたいランダムIDで構成されていることです。連続している必要はなく、一意である必要があります。あなたは宇宙のすべてが欲しいですか？ 

SELECT * 
FROM #locations
WHERE id like '10%'

あなたは4レベル下の何かが欲しいですか？ 

SELECT * 
FROM #locations 
WHERE id like '10000%'

非常に多くのレベルを下げると、IDが少し長くなる可能性がありますが、単純なクエリを作成する場合、それは本当に重要ですか？また、これは単なる文字列であるため、インデックスを再作成しなくても、非常に多くの拡張性を実現できます。

于 2012-06-01T22:13:57.890 に答える