問題タブ [normalization]

私はデータベースに非常に慣れていないので、簡単な質問があります。

次のフィールドがある場合、MySQLデータベースをどのように設計しますか？

ID、緯度、経度、日付-複数の日付、時刻-複数回

私はそれを2つのテーブルに入れるべきだと知っていますよね？そして、これら2つのテーブルはどのように見えますか？

ありがとう！

イベントを繰り返すアプリケーションがあります。したがって、イベントは、日ごとに「n 日ごと」、週ごとに「月/火/水/その他の n 週間ごと」、月ごとに「1 日、2 日、3 日などに n か月ごと」に繰り返すことができます。

テーブル設計の観点からこれを処理する最良の方法は何ですか? 2つの方法を考えることができますが、どちらが優れているかはわかりません。

1) 上記の 5 つの列、日のケースに 1 つ、週と月にそれぞれ 2 つの列。使用されていないものは null になります。私のアプリケーションでは、null が表示され、それらを無視することを選択できました。

2) 2 番目のテーブル (events_dateinfo など) を作成し、クエリで JOIN します。

オプション 2 はおそらくより「正規化」されているようですが、そうでないこともありますが、そのような単純なことに対してやり過ぎだと思いますか? また、オプション 2 に行く場合、行を列に変換する方法はありますか?つまり、特定のイベントの 2 週間の属性を選択し、それらを列として扱う方法はありますか?

通常、データの冗長性を回避するためにデータベースを正規化します。名前でいっぱいのテーブルを見ると、冗長性が十分にあることが簡単にわかります。あなたの目標が地球上のすべての人の名前のカタログを作成することである場合（幸運）、名前を正規化することがいかに有益であるかがわかります。しかし、平均的なビジネスデータベースのコンテキストでは、それはやり過ぎですか？

（もちろん、私はあなたが極端に何かを取ることができることを知っています...あなたが音節に正規化した場合...または隣接する文字のペアさえも。私はそこまで行くことの利点を見ることができません）

アップデート：

これを正当化できる理由の1つは、ランダムな名前ジェネレーターです。頭のてっぺんから思いつくのはそれだけです。

データベースのドラフト設計は何ですか？それは設計プロセスであり、次のような手順ですか。

• データベースの目的を決定する
• 必要な情報を見つけて整理する
• 情報を表に分割する
• 情報項目を列にする
• 主キーの指定
• テーブルの関係を設定する
• デザインを改良する
• 正規化ルールを適用する

それとも別物ですか？？？ありがとう

だから私は、私が制御できないデータベースと対話するphp Webサイトをコーディングしている職場でこのプロジェクトに取り組んできました。データベースは、私よりも長い間会社に勤務している同僚によって「設計」されました。したがって、最終的な決定は彼らの決定に任されています。

このプロジェクトに初めて参加したとき、同僚のところに行き、データベース スキーマに欠陥があるようだと説明しました。データベースを正規化してデータの整合性の問題を確実にし、ディスク領域を節約することの重要性と、プログラマー (私) の仕事を容易にすることを説明しました。挿入、削除、および更新の異常が現在の設計でどのように発生するかの例も示しました。それにもかかわらず、同僚は、プロジェクトのデータベースを過度に複雑にしたくないので、期間を変更しないと説明してくれました。

そのため、プロジェクトを開始して数か月が経ちましたが、2 つのテーブルを結合して、互いに 1 対 1 の関係を持つ属性に値を挿入する必要があるたびに、頭を悩ませています。(したがって、属性は単にメイン リレーションの属性である必要があります。) データベースは見栄えが悪く、データベースを使用するフロント エンドをプログラムしたので、数年後にこれが戻ってくるのではないかと心配しています。

「上司」の同僚にデータベースを正しく設計するよう説得する方法について、誰か提案はありますか? または、私が何の役にも立たなかったデザインのために何年も愛用されないようにする方法についての提案はありますか? 今後、このようなプロジェクトに取り組むことを拒否する必要がありますか? 私のコードにコメントを残して、データベースは私がやったことではないということですか?

ありがとう。

編集：コメントへの追加情報...

データベースの非正規化が速度向上に役立つことはわかっているので、これを見落としているわけではありません。この戦術について聞いたことがない読者のために、例を示します。多くの場合、データベース設計者は、ユーザーの番地、都市、州、および郵便番号をリストする住所関係を持っています。郵便番号が都市と州を決定することは誰もが知っているため、郵便番号を都市と州にインデックス付けするテーブルを構成します。多くの場合、データベース設計者は 2 つのテーブルを結合し、ユーザーのアドレスに対するすべてのクエリでアドレス テーブルから zip テーブルへの結合が必要になることを予測して非正規化します。これにより、最終的にクエリ処理が高速化され、データベース設計の一部を非正規化する正当な理由になります。

ここに詳細を入力するために、データベースはツアー リクエスト システム用に設計されているため、内部のデータは訪問者情報、日付などに関連しています。現在のデータベースが使用するスキーマは、最初から最後まで予測できません。変数の命名パターン (例: num_of_visitors、arrivalMethod など) の最も単純な矛盾から、単一の状態の 1 対 1 の属性に対して定義された別個の関係を持つことまで。例: statusID はツアー リクエストのステータスを表します。有効な状態は、可能な状態 (承認済み、拒否、保留中、キャンセル済み) のグループから選択された 1 つのみです。何らかの理由で、データベースには以下を含むステータス テーブルがあります: tour_id(Primaryツアー関係のキー)、statusID. これにより、ツアー リクエストごとに複数の状態を定義できます。これは、設計上、ツアー リクエストが常に 1 つの状態にある必要があるためです。

メンバーシップ テーブルとメーリング リスト テーブルの 2 つのテーブルがあります。

• 果物の列はユーザ​​ーの好みです。

と

• メーリングリスト作成者はニュースレターの受信を選択できますが、必ずしもメンバーである必要はありません

メーリングリストの設定の保存を開始したいと思います。私の質問は、これら 2 つのテーブルのデータを統合する最良の方法は何でしょうか?

ユーザー名、パスワードなどのメンバー情報のみを格納するメンバー テーブルと、電子メール アドレスと設定を格納する別のプロファイル テーブルを実験しました。メンバーとメーリング リストの両方の設定をこのプロファイル テーブルに保存できますが、FK 制約を追加できず、メーリング リスト作成者を追加できません。

だから今私のオプションは次のとおりです。

1. 2 つのテーブルに固執しますが、メーリングリスト テーブルに重複した「設定」列を導入します。
2. 単一のプロファイル テーブルとねじの参照整合性を使用します。

または、別のより良い方法がありますか？

カレンダーアプリケーションを書きたいです。DB スキーマの作業に支障をきたすのは、本当に繰り返し発生する項目です。これを整理する方法について、いくつかの意見をいただければ幸いです。

ユーザーがイベントを作成し、それが月曜日に全員に繰り返されることを入力した場合はどうなるでしょうか? それをすべてデータベースに保存するにはどうすればよいでしょうか。無限のイベントを作成することはできません。すべてのイベントがどこに行くのかを計算できるように、関連情報を保持するテーブルをそこに置くだけですか? もしそうなら、ユーザーがカレンダーの新しい部分を表示するたびにそれらを計算する必要があります。月ごとにページをめくっていても、定期的なアイテムが大量にある場合はどうなるでしょうか?

また、スキーマは、ユーザーがアイテムをクリックして、シーケンス内のすべてのアイテムではなく「シーケンス内のこのアイテムを編集してください」と言ったときに処理する必要があります。次に、シーケンスから 1 つの項目を分割しますか?

更新 1

私はiCalをまったく見ていません。明確にするために、定期的なアイテムを計算できる情報を保存し、シーケンスと異なるものを分割することは、それを転送できるように保存するための優れた方法だと思います. しかし、アプリケーションでは、これは遅すぎて、いたるところで日付計算を行うことができないと思います。

正規化されたデータベースがあり、複数のテーブル間の結合を含むWebベースのレポートを頻繁に作成する必要があります。これらのクエリには時間がかかりすぎるため、ページをすばやく読み込むことができるように、結果を計算したままにしておきたいと思います。私が要約しているテーブルは頻繁に更新されており、これまでのすべての更新を反映するために要約が必要です。

すべてのテーブルには自動インクリメントの主整数キーがあり、ほとんどの場合、新しい行を追加して、計算結果をクリアするように調整できます。

テーブルの各行を反復処理し、イテレータの状態と見られた最高のプライマリキーン（つまり「ハイウォーター」）を追跡することで、単一のテーブルの要約が必要な同様の問題に取り組みました。これは単一のテーブルの場合は問題ありませんが、複数のテーブルの場合、テーブルごとに1つの高水位値を維持することになり、それは複雑に感じます。または、1つのテーブルに非正規化することもできます（アプリケーションをかなり大幅に変更します）。これは一歩後退したように感じ、データベースのサイズを約5GBから約20GBに変更する可能性があります。

（現在、sqlite3を使用していますが、MySQLもオプションです）。

同僚が新しいテーブルの値を次のようにスケッチしました。

これらは、テーブル内の唯一の列です。列名は Col1、Col2 です。

ある人は、この表は正規化されていないと言い、別の人は正規化されていると言いました。

正規化に違反したという具体的な議論は、Col1 の「Foo」で「Foo」を含む 3 つのレコードを削除すると、システムに存在しなくなるというものです。その人は、ID と Name 列を含むルックアップ テーブルが必要だと言いました。上記のテーブルは、そのテーブルの Id をその FK として参照します。

正規化されていないという議論は、最初の列 (3 番目の正規化された形式) に依存するテーブルに 3 番目の列がなかったことです。

私が思う混乱は、この例を満たすという点で 1NF であることから来ています。

http://en.wikipedia.org/wiki/Database_normalizationから。

しかし、「同じ情報を複数の行で表現できるため、テーブルを更新すると論理的な矛盾が生じる可能性がある」というルールに違反しているように聞こえます。これは、1NF を超える正規化に適用されます。

したがって、元のテーブルは 2NF に違反し、それによって 3NF に違反するように見えますが、1NF は満たします。これは正しいです？

mp3 ファイルの平均音量を知る必要があるので、(異なるビットレートで) mp3 に変換するときに、音量もスケーリングして正規化できます...

したがって、平均音量を dB で表示するコマンド ライン ツール / ruby​​ ライブラリが必要です。