問題タブ [normalization]

画材屋の申込書を書いています。私のシステムには、shop、cart place、rack、bakery というクラスがあります。

これらには次のプロパティがあります。

ショップ: X、Y、名前、幅、高さ、種類、住所

カートの場所: X、Y、名前、幅、長さ、タイプ、容量

ラック: X、Y、名前、幅、長さ、タイプ、高さ、balance_limit

ベーカリー: X、Y、名前、幅、長さ、タイプ、open_hours

今、データベースでこれらのクラスを表現したいと思います。しかし、ご覧のとおり、上記のすべてのクラスには次のような同じものがあります。

X、Y、幅、高さ、名前、タイプ。そして、それらの違いは次のとおりです。

ショップ：住所

カート置き場：定員

ラック: balance_limit

ベーカリー: open_hours

将来、これらすべてのタイプのオブジェクトが独自の新しいプロパティを持ち、それらすべてが一度に持つ新しいプロパティを取得することを私は知っています.

また、ショップ、カート置き場、ラック、ベーカリーと同じプロパティを持つ、上記以外の新しいタイプのオブジェクトが存在することもわかっています。

新しいプロパティと新しいオブジェクトを追加できるデータベース構造を作成したいと考えています。また、すべてのクラスに同時に追加される新しいプロパティを追加します。さらに、システムを明確に設計して、データベースへの簡単なクエリを実行できるようにしたいと考えています。

だから私の質問は：

オブジェクトのすべてのタイプ (ショップ、カート置き場、棚、ベーカリー) のデータベース テーブルを作成する必要がありますか?

あるソリューションが別のソリューションより優れている理由を教えてください。ここで、「公理だから正しい方法だからやるべきだ」だけでなく、実用的なアドバイスを得たいと思っています。

私は、SQL Server 2008/LinqToSQL/カスタムメイドのリポジトリを DAL として使用して、マルチユーザーのインターネット データベース駆動型 Web サイトに取り組んでいます。正しく悪用された場合、一貫性のないデータベース状態につながる可能性がある正規化の問題に遭遇しました。この問題をどのように処理するかを考えています。

問題: 複数の異なる会社が私の Web サイトにアクセスしています。彼らは私のウェブサイトで彼らのプロジェクトとクライアントを追跡できるはずです. プロジェクトの一部 (すべてではない) をクライアントに割り当てる必要があります。

これにより、次のデータベース スキーマが生成されます。

これにより、次の関係が生まれます。

ここで、悪意のあるユーザーは、たとえば、自分の CompanyID を持つプロジェクトを挿入する可能性がありますが、別のユーザーに属する ClientID を使用して、データベースを矛盾した状態のままにする可能性があります。

この問題は、データベース スキーマ全体で同様の方法で発生するため、可能であれば一般的な方法で解決したいと考えています。次の2つのアイデアがありました。

• DAL の不整合につながる可能性のあるデータベース書き込みを確認します。これは一般的な方法ですが、更新クエリと作成クエリを実行する前に追加のデータベース クエリが必要になるため、パフォーマンスが低下します。

• クライアントとプロジェクトの関係用に追加のテーブルを作成し、この方法で作成された関係が一貫していることを確認します。これには追加の選択クエリも必要ですが、最初のケースよりもはるかに少なくなります。一方で、それは一般的ではないため、特にデータベースにテーブルや依存関係を追加する場合は、長期的に見逃す可能性が高くなります。

あなたならどうしますか？私が見逃したより良い解決策はありますか？

編集:なぜ Projects テーブルに CompanyID があるのか​​不思議に思うかもしれません。これは、ユーザーがクライアントの有無にかかわらずプロジェクトを追加できるようにするためです。クライアントレス プロジェクトがどの会社 (したがって、どの Web サイト ユーザー) に属しているかを追跡する必要があります。これが、プロジェクトに CompanyID が必要な理由です。

患者の仮想コホートの生理学的特性 (収縮期血圧、トリグリセリド濃度など) のパラメトリック記述を格納するデータベース テーブルを作成する必要があります。

たとえば、ユーザーが SBP の三角分布を指定すると仮定すると、最小値、最大値、最頻値 (および分布タイプ) を保存する必要があります。別の方法として、平均値と標準偏差の保存を必要とする正規分布を指定することもできます。

これらのデータを正規化する正しい方法に苦労しています。現在、次のように多数の 1 対 1 の関係を持つ Cohort テーブルと Distribution テーブルがあります (一部のフィールドは省略されています)。

(distribution_type は、分布を説明する文字列を保持します: "Triangular"、"Weibull" など)。

Distributions の各行に NULL フィールドが大量に残っているため、これが最適な方法ではないことは確かです。

私のもう1つの考えは、分布タイプごとに個別のテーブル（三角形用、ガウス用、均一用など）を作成し、中央にid列（コホートの外部キーとして使用される）を持つテーブルを作成することでした。テーブル *_dist 列)、適切な分散テーブルに行の外部キーを格納するための分散型列と id 列。

クエリは、Cohort 列に格納されている ID を使用して、中央のテーブルから分散タイプと行 ID を検索し、ID を使用して適切なテーブルのパラメーターを検索します。ただし、文字列を使用して適切なテーブルを選択し、別の ID を使用して適切な行を選択することは、従来の JOIN とはかけ離れており、あまりクリーンなアプローチとは思えません。

それで、これを最もよく達成する方法（正規化および/またはパフォーマンスの観点から）に関する提案はありますか？

どうもありがとう、リッチ

私はクライアントのためにローイングレポートと統計システムを作成しています。現在、次のような構造になっています。

これはデータの行の例ですが、これをRowersテーブルやCoachesテーブルなどに拡張したいのですが、これをエントリテーブルにリンクする方法がわかりません。

誰かが私と共有できる知恵の言葉を持っていますか？

アップデート

チームは任意の数のコーチと漕ぎ手を持つことができ、漕ぎ手は多くのチーム（チームA、B、Cなど）に属することができ、チームは多くのコーチを持つことができます。

私が取り組んでいるWebアプリケーションで、予期しない「バグ」が発生しました-アプリのデータベースには、「States」と「Cities」という2つのテーブルがあります（他にも多数あります）。

'状態'テーブルフィールド：

' idStates 'は、自動インクリメントの主キーです。

'都市'テーブルフィールド：

' idAreaCode 'は、国コード+市外局番で構成される主キーです（たとえば、91422はインドの国コード、422はインドの都市の市外局番です）。' idStates 'は、' States 'テーブルから派生した外部キ​​ーであり、' Cities 'テーブル内の各都市を対応するStateに関連付けます。

国コードと市外局番の組み合わせは都市ごとに一意であるため、主キーとして安全に使用できると考えました。すべてが機能していました。しかし、インドのある場所では、データベース設計に予期しない「欠陥」が見つかりました。米国のように、インドは連邦民主主義であり、地理的に多くの州または連邦直轄領に分割されています。州と連邦直轄領の両方のデータが「州」テーブルに保存されます。ただし、 2つの州（ハリヤーナ州とパンジャブ州）に属し、それ自体が連邦直轄領でもある1つの場所（チャンディーガル）があります。

明らかに、現在のデータベース設計では、都市「チャンディーガル」の複数のレコードを保存することはできません。

提案された解決策の1つは、列' idAreaCode 'と' idStates 'を組み合わせた主キーを作成することです。

これが可能な最善の解決策であるかどうか知りたいですか？

（参考：InnoDBエンジンでMySQLを使用しています）。

詳しくは：

• データベースには、各都市の気象情報が格納されています。したがって、州と市は各クエリの開始点です。
• 各都市の最新データは、CSVファイルを使用して毎日挿入されます。CSVファイルには、各レコードを識別するために使用されるidStates（州の場合）およびidAreaCode（都市の場合）列が含まれています。
• データベースの正規化は私たちにとって重要です。

注：都市テーブルに自動インクリメントの主キーを使用しない理由は、データベースがCSVファイル（別のアプリによって生成されたもの）を使用して毎日/毎時更新されるためです。また、CSVファイルの各レコードは、idStates列とidAreaCode列で識別されます。したがって、都市テーブルで使用される主キーは、テーブルが削除されて再度更新された場合でも、すべての都市で同じであることが望ましいです。郵便番号（またはPINコード）と市外局番（またはSTDコード）は、一意で静的（頻繁に変更しない）であるという基準を満たし、これらのリストを簡単に入手できます。（インドはPINコードを新しい形式に更新中であるため、今のところ市外局番を決定しました）。

私たちが決定した解決策は、データベース設計に変更を加えるのではなく、アプリケーションレベルでこれを処理することでした。データベースには、「チャンディーガル」のレコードを1つだけ保存します。このアプリケーションでは、検索をこのレコードにリダイレクトするために、「Chandigarh、Punjab」または「Chandigarh、Haryana」の検索用のフラグを作成しました。ええ、それは理想的ではありませんが、これが私たちがこれまでに遭遇した唯一の例外であるため、許容できる妥協案です。

私はまもなく、（仕様から）StackOverflowを少し思い出させるプロジェクトの作業を開始します。基本的に、ユーザーが制御するコンテンツを持つWebアプリです。

私が頭の中で輪になって回っている機能の1つは、バージョン管理です。ここStackOverflowでは、各質問と回答に複数のリビジョンを含めることができます。これは、オブジェクトのタイプ（この場合はそのテキスト）が1つしかない場合に実装するのは非常に簡単です。

だから、私の単純なページについては、私は設定されています。

問題は、バージョン管理下にある必要のあるいくつかのオブジェクトに関係があると考えるときに発生します。具体的な例を示すために、ランダムな類似ドメインを選択します。

本/著者情報を追跡するためにWikiのようなサイトを実装していたとしましょう。このサイトの主な焦点は、「作成者」ページを作成および更新することです。これは、テキストとしては非常に単純です（上記のとおり）。ただし、著者と本の間に1対多の関連付けを追加しましょう（つまり、人が多くの本を作成できることは明らかであるため、本は別個のオブジェクトになります）。各本には、著者ページからその本に関する情報ページへのリンクがあります。

ユーザーにとって、著者を説明するテキストベースの「要約」と、その著者と彼らの作品との間のリンクとの間にほとんど違いはありません。したがって、著者ページ、書籍ページ、および著者と書籍の関連付けに「改訂」/編集機能を実装する必要があります。つまり、ユーザーは、著者ページ、書籍ページ、および2つの間の関連付けを編集、履歴の表示、およびロールバックできる必要があります。

その関係が多対多になると、これはさらに複雑になり、複数の著者が本に寄稿したとリストされる可能性があります。

私はいくつかの解決策を考えていますが、どれも私が望むほどきれいではありません（そして少なくともいくつかの繰り返しのコード/冗長データストレージを含みます）、そして私はここの至る所で共通点を見ますが、私は感じます特にデータベースレベルでは、実際にそれを最適に抽出することはできませんでした。与えられた答えにバイアスをかけたくないので、すぐに答えるつもりはありません。

では、このシステムをデータベースレベルでどのように設計しますか？ここでテーブルの仕様を探しています。すぐにわからない場合は、テーブルの仕様とその使用方法の説明を探しています。関連する可能性のある回答については、ASP.NETと、Linq-to-SQL（LTSの多対多に慣れている）またはEntityFrameworkのいずれかを使用します。

編集：明確にするために、私は基本的なDB設計、正規化、多対多のマッピングテーブルなどを理解しています。私はこの特定の状況に対するクリーンなソリューションを探しています。

編集2：システムには単なる本よりもはるかに多くのサブオブジェクトがある可能性があるため、一般化可能なソリューションを探しています。作者は他の作者、雑誌、イベントなどと関係があるかもしれません。一人一人に歴史を実装していくと、たくさんの仕事を繰り返しているような気がします。

2 つのテーブルに正規化したい重複行を含むテーブルがあります。

これを 2 つのテーブル (user と url_keyword) に正規化することから始めたいと思います。これを正規化するために実行できるクエリはありますか、それともテーブルを構築するためにスクリプトを使用してテーブルをループする必要がありますか?

SQLの知識を超えてデータベースを正規化したと思います。:)これが私のスヌーカーリーグのウェブアプリから苦労しているクエリです。これは、すべてのシーズンのチームのハイブレイクの全体的な統計を計算します。サンプルのチームID3では。

テーブル：

• 一致：

• 休憩：

• team_members：多対多のテーブル。

上記のクエリは、1つの問題を除けば、ほぼ意図したとおりに機能します。プレーヤーが複数のチームでプレーした場合、すべてのチームで彼が持っている休憩がこれらの統計に含まれます。

Breaksテーブルに追加のフィールド「break_team」がある場合、クエリは簡単です。だから私の質問は2つあります、誰かが正しいクエリを支援できますか、それともこれらの統計を支援するために正規化を少し減らす必要がありますか？非正規化する時期はいつですか？

既存のWebアプリがあり、ユーザーが既存のオブジェクトにタグを付けることができるようにタグ機能を追加したいと思います。問題は、各オブジェクトにタグ列を追加する必要があるかどうかです。または、それを正規化して、各オブジェクトにタグのコレクションがあるタグテーブルを使用する必要がありますか？私は後者に傾倒しています。なぜなら、それはよりクリーンで、レポートしやすく、タグクラウドを作成しやすいからです。しかし、これが1000回解決されたことを知っているので、何かが足りないかどうかを尋ねて確認したいと思いました。

3 つのテーブルとしてリファクタリングしたい、繰り返しデータがたくさんあるテーブルがあります。

現在の構造は次のようになります。

current_table のデータは次のようになります。

シーケンスからの PK を使用して、ミーティング テーブルとトピック テーブルを作成したいと思います。

私が理解できないのは、新しいテーブルにデータを挿入する方法です。私はもう試した：

しかし、もちろんそれはうまくいきません。データを正規化する簡単な方法はありますか?