3

しばらくの間、私を混乱させた SQL の決定について助けが必要です。

私は、ユーザーが自分のストーリーを書いたり、他のユーザーのストーリーを閲覧したりできる短編小説の Web サイトを作ろうとしています。また、過去の偉大な作家によって書かれた古典的な短編小説のコレクションもあります。両方のタイプのストーリーを同じデータベース テーブルに格納する必要があるかどうかについて混乱しています。

Web サイトを検索して結果からユーザー ストーリーを除外できるはずなので、2 種類のストーリー (従来の作成者/ユーザー) をある程度区別したいと考えています。しかし、これを表すデータベース行をテーブルに 1 つだけ持つことはできません。つまり、ブール値の CLASSIC です。古典的な短いストアでは、他のいくつかの行も異なるためです。ユーザーがいないため、日付は YYYY (つまり、1869) ユーザーが送信した完全な日時の代わりに。

それでも、それらを別々の表に入れることを正当化することはできません。ほとんどの属性が同じ場合、ショート ストーリー用に 2 つの異なるデータベース テーブルを使用する必要がありますか? 現時点では、古典的な短編小説のユーザー行に NULL を入力しています。フィルタリングされた検索には、ユーザーが NULL であるデータベースから選択する古典のみを検索するオプションがあります。ただし、数千の古典的なストーリーを見つけるためだけに、潜在的に数百万のユーザーストーリーの巨大なデータベースを検索している場合、これはパフォーマンスに影響を与えるようです.

短編小説テーブルにリンクされた、ストーリーのタグなど、他のテーブルもあることに注意してください。

だから私は基本的に SQL の専門家に質問しています - 2 種類の情報を別々のテーブルに分ける十分な理由はありますか? 現在、開発に SQLite を使用していますが、後で MySQL または PostgreSQL に切り替える予定です。

4

2 に答える 2

4

私はおそらく、次のようなテーブル間で主キーが一致する「親子」テーブル構造を使用します。

Stories: StoryId (PK), StoryType (U or C), StoryText, etc. (all of the shared stuff)
UserStories: StoryId (PK and FK), UserId, etc.
ClassicStories: StoryId (PK and FK), AuthorName, etc.

次に、必要に応じて、それらの周りに 2 つのビューを構築できます。

V_UserStories: StoryId, StoryText, UserId, etc.
V_ClassicStories: StoryId, StoryText, AuthorName, etc.

このセットアップでは、列を無駄にすることはなく、共有されたものを一緒に保ちながら、必要に応じて 2 種類のストーリーを論理的に簡単に分離できます。

于 2013-10-21T19:54:25.463 に答える
0

このような決定を下すには、テーブルに挿入するフィールドがテーブルのみで、他には何もないかどうかを考える必要があります。例えば

ストーリーとストーリーのタイプ。ストーリーが複数のタイプのストーリーおよび/または複数のストーリーのタイプを持つことができる場合、はい、特定のテーブルの種類の履歴を作成する必要がありますが、1 つのタイプのストーリーのみが 1 つのストーリーに関係する場合は、タイプを挿入します情報 (名前、説明など...) をストーリー テーブルに直接追加します。

于 2013-10-21T20:02:24.810 に答える