1

私の会社は毎年グルメフェスティバルを開催しています。祭りの期間中、多くのイベントが開催されます。私はCMS（コンテンツ管理システム）を使ってフェスティバルのウェブサイトをデザインする任務を負っています。

エンティティには、イベント、設立、個人の3つの主要なタイプがあります。イベントには多くの参加施設（スポンサー、レストラン、ホテル）と人（シェフ、ワイナリーの代表者、ミクソロジスト）が参加しています。

各エンティティには、多くのカテゴリ、多くのドキュメント、フォトギャラリー、および他のタイプのエンティティへのリンクを含めることができます。どちらが良いですか-ケース1またはケース2（以下を参照）？

[ケース1] -各エンティティタイプのテーブルのセット：

イベントのテーブル：event、eventCategory、eventDocument、eventGallery、event_establishment、event_person

確立のためのテーブル：確立、確立カテゴリー、確立ギャラリー、確立_人

Personのテーブル：person、personCategory、personDocument、personGallery

personDocumentテーブルのサンプル列：docId、docFilename

上記の列は、eventDocumentとestablishmentDocumentでまったく同じになることに注意してください。

[ケース2] -各エンティティタイプのテーブル、タイプテーブル、およびテーブルの一般的なセット：

テーブル：event、establishment、person、entityType、entityCategory、entityDocument、entityGallery、entity_entity

entityDocumentのサンプル列：docId、entityTypeId、docFilename

アドバイスに感謝します-ありがとう！

4

1 に答える 1

0

これは私の意見ですが、私はこれをしばらくやっています。

ケース1は、保守がはるかに簡単で、私の経験では最も推奨されています。エンティティを管理でき、サイトの作成に使用している言語に応じて、生活をさらに楽にするいくつかのORMフレームワークの利点について話すことができます。

ケース2、SQLデータベースでこれを行うと、多くの問題が発生します。型を検出するために不要なコードをたくさん書くことになり、正しい結合を行っていることを確認してください。悪夢になります！私は本当にそれをこのようにすることの利点を考えることができません。

No-SQLデータストアのケース3が考えられます。MongoDBやRavenDBのように。気になる構造はありません。あなたが入れるものはあなたが出すものであり、翻訳は一切ありません。（少なくともRavenDBを使用）。いいえ-SQLDataストアは、大規模なアプリケーションの場合ははるかに高速ですが、正しく使用するためには時間がかかります。

ケース1に行くことをお勧めします

于 2013-03-07T10:33:29.713 に答える