問題タブ [normalizing]

ログ ファイルの解析が必要なプロジェクトに取り組んでいます。次のようなグループメッセージを受け取る高速なアルゴリズムを探しています:

P1 の温度は華氏 35 度です。

P1 の温度は 40F です。

P3 の温度は華氏 35 度です。

ロガーが停止しました。

ロガーを開始しました。

P1 の温度は 40F です。

printf() の形式で何かを出力します。

アルゴリズムは、メッセージ グループ内のほぼすべてのデータ ロードを認識できるように十分に汎用的である必要があります。

この種のテクノロジーを検索してみましたが、検索する正しい用語もわかりません。

ユーザーの連絡先情報を保存する必要があります。このデータをhCardとしてページに表示し、 vCardとしてダウンロード可能にしたいと考えています。また、電話番号、メールなどでデータベースを検索できるようにしたいと思います。

このデータを保存する最良の方法は何だと思いますか? ユーザーは複数のアドレスを持つことができるため、完全な正規化は混乱します。XML の使用を考えていますが、XML db フィールドのクエリに慣れていません。連絡先情報でユーザーを検索することはできますか?

問題があれば、SQL Server 2005 を使用しています。

以前の同僚は、テーブル数が多く、列数が少ないデータベースの方が、テーブル数が少なく、列数が多いデータベースよりも優れていると主張しました。たとえば、名前、住所、都市、州、郵便番号などの列を持つ顧客テーブルではなく、名前テーブル、住所テーブル、都市テーブルなどを作成します。

彼は、この設計はより効率的で柔軟であると主張しました。おそらくより柔軟ですが、その効率性についてコメントする資格はありません。たとえそれがより効率的であったとしても、それらの利点は、追加された複雑さによって上回る可能性があると思います.

So, are there any significant benefits to more tables with fewer columns over fewer tables with more columns?

さて、今「ボックスアイテム」の表を作っています。

現在、ボックスアイテムは、使用目的/アイテムのステータスに応じて、「配送」ボックスまたは「返品」ボックスに関連付けられる場合があります。

ボックス アイテムに欠陥がある可能性があります。欠陥がある場合、ボックス アイテムの行にフラグが設定され (IsDefective)、ボックス アイテムは「返品」ボックスに入れられます (他のアイテムはそのベンダーに返品されます)。それ以外の場合、ボックス アイテムは最終的に「配送」ボックスに入れられます (他のアイテムが配送されます)。(配送ボックスと返品ボックスには独自のテーブルがあることに注意してください。すべてのボックスに共通のテーブルが 1 つあるわけではありませんが、可能であれば 3 つ目の可能性としてそれを検討する必要がありますか?)

今日ははっきりと考えていないだけかもしれませんが、この状況で何をすべきか疑問に思い始めました。

私の直感では、一度に 1 つのリレーションしか発生しない場合でも、考えられるリレーションごとに個別のフィールドが必要であることがわかります。これにより、ボックス アイテムのスキーマは次のようになります。

BoxItemID 説明 IsDefective ShippingBoxID ReturnBoxID など...

これによりリレーションが明確になりますが、無駄に思えます (リレーションは常に 1 つしか使用されないため)。そこで、BoxID 用のフィールドを 1 つだけ用意し、IsDefective フィールドに基づいて、それが参照している BoxID (配送または返品ボックス ID) を判断できると考えました。

BoxItemID 説明 IsDefective BoxID など...

これは無駄が少ないようですが、私には合いません。関係は明らかではありません。

それで、Stackoverflow のデータベースの達人であるあなたにそれを言います。この状況であなたはどうしますか？

編集: ご意見をお寄せいただきありがとうございます。いろいろ考えさせられました。1 つには、次にこのようなプロジェクトを開始するときに ORM を使用するつもりです。=) 2 つについては、私は今いないので、4 バイトをかじって 2 つのフィールドを使用します。

みんなありがとう！

1 つのディメンション内で重複しない範囲を格納できるデータ構造が必要です。次元の全範囲を完全にカバーする必要はありません。

例としては、会議室のスケジューラーがあります。次元は時間です。2 つのスケジュールが重複することはありません。会議室は常にスケジュールされているわけではありません。つまり、特定の時間に存在できるスケジュールは最大 1 つです。

簡単な解決策は、範囲に開始時刻と終了時刻を格納することです。

これは正規化されておらず、コンテナが重複しないようにする必要があります。隣接する 2 つの範囲の場合、前の終了は次の開始と冗長になります。

別のスキームでは、各範囲に 1 つの境界値を格納する必要があります。ただし、範囲の連続したシーケンスでは、範囲よりも 1 つ多くの境界値が常に存在します。これを回避するには、シーケンスを交互の境界値と範囲として表すことができます。

B = 境界値、r = 範囲

ぶんぶん

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

本質的に、これは交互の型を持つ二重連結リストです。

最終的には、使用するデータ構造が何であれ、メモリ (アプリケーション コード) とリレーショナル データベースの両方で表現されます。

学術的または業界が試みたソリューションが存在することに興味があります。

テーブルを分岐するという繰り返しの問題を止めるための戦略を探しています。たとえば、架空のユースケースとして、名前、ログイン、パスワード、およびその他のメタデータを含むユーザーのテーブルがあるとします。この特定のシナリオでは、ユーザーが IP の特定のサブセットごとにログインするように制限されているとします。したがって、1:M の関係があります。次のようなユースケースが発生するたびに、通常のワークフローには「users」テーブルと「user_ips」などのテーブルが含まれます。この場合、pk(ip_id)、fk( user_id) と user_ips 側の IP。

同様の状況で、皆さんは通常、上記のようにファンアウトしますか? ここで効果的に非正規化する機会はありますか? おそらく、CSV で区切られた方法で IP を BLOB 列に保存しますか? 皆さんが現在展開している戦略は何ですか?

オブジェクトのタグ付けにMySQLデータベースを使用するPHP Webアプリケーションがあります。このSOの質問への回答として受け入れられたタグ構造を使用しました。

各タグが一意の親タグを持つことができるタグ階層を実装したいと思います。親タグ T の検索は、T のすべての子孫 (つまり、T、親が T であるタグ (T の子)、T の孫など) に一致します。

これを行う最も簡単な方法は、タグの親タグの ID を含む ParentID フィールドをタグ テーブルに追加するか、タグに親がない場合は何らかのマジック ナンバーを追加することです。ただし、子孫を検索するには、データベースを完全に検索して各「世代」のタグを見つける必要がありますが、これは避けたいと思います。

(おそらく) より高速ですが、正規化されていない方法は、各タグのすべての子、または各タグのすべての子孫を含むテーブルを作成することです。ただし、これにより、データベース内のデータに一貫性がなくなる危険性があります (たとえば、タグが複数の親の子であるなど)。

データを可能な限り正規化しながら、クエリを作成して子孫をすばやく見つける良い方法はありますか?

5つのテーブルとルックアップテーブルに正規化する必要がある1つの大きなアクセスデータベースがあります。私は正規化の背後にある理論を理解しており、すでにテーブルの外観をスケッチしていますが、データベースを正規化するためにテーブルを変換する方法に迷っています。テーブルアナライザーは、私が望む内訳を提供しません。

適切に正規化されていない古いデータベースを維持する必要があります。たとえば、注文から納品日までのプロジェクトのさまざまなマイルストーンに対して、5つ以上の異なる日付列を持つように成長した（またはキノコになっている）プロジェクトテーブルがあります。番地、メールアドレス、またはWebリンクの列がそれぞれにあるテーブルもいくつかあります。

構造を正規化し、住所や予定日などのテーブルを作成し、1：Nの関係（顧客ごとの住所、プロジェクトごとの期日など）を可能にするために必要なテーブルを作成したいと思います。

現在、詳細テーブルのデータへの変更を処理する方法が完全にわかりません。たとえば、顧客の配送先住所の変更について考えてみます。複数のレコード（場合によっては複数のテーブル内）がそのレコードを参照する可能性があるため、アドレステーブルのデータを変更することは問題外です。新しいアドレスレコードを追加すると、他の行に外部キー関係がない場合、古いレコードが孤立したままになる可能性があります。

私はこれを処理するために次の方法について考えました：

• 新しい詳細レコードを追加し、マスターテーブルの更新トリガーをチェックインして、古い詳細レコードを削除する必要があるかどうかを確認します。これには、詳細テーブルと関係のあるすべてのテーブル、それらすべて、またはsprocに関する知識が必要になります。私はこの分離の喪失が好きではありません。また、アクティブなトランザクションにより多くのテーブルが含まれます。

• トリガーに古い詳細レコードの削除を試みさせ、エラーをキャッチします。これはただ間違っていると感じます。

• 孤立したレコードを使用して、定期的なメンテナンスタスクですべての詳細テーブルをクリーンアップします。

複数のマスターテーブルにリンクされている詳細テーブルのデータ変更を処理するための推奨される方法は何ですか？これを読むためのヒントはありますか？

私の雇用主である小規模な事務用品会社は、サプライヤを切り替えようとしています。私は、堅牢なデータベース スキーマを作成するために、サプライヤの電子コンテンツを調べています。私たちの以前のスキーマは、ほとんど何も考えずにまとめられただけであり、破損した一貫性のない情報を含む耐え難いデータ モデルにつながっています。

新しいサプライヤーのデータは古いものよりもはるかに優れていますが、彼らのデータは私が超正規化と呼ぶものです. たとえば、製品カテゴリ構造には、マスター部門、部門、クラス、サブクラス、製品ブロックの 5 つのレベルがあります。さらに、製品ブロックのコンテンツには、製品の長い説明、検索用語、および画像名があります (製品ブロックには製品とすべてのバリエーションが含まれているという考えです。たとえば、特定のペンは黒、青、または赤のインクで提供される場合があります。これらすべてアイテムは本質的に同じものであるため、単一の製品ブロックに適用されます)。私が与えられたデータでは、これは製品ブロックの一意の ID への参照を持つ製品テーブル (「テーブル」と言いますが、データを含むフラット ファイルです) として表されます。

提供されたデータに対応する堅牢なスキーマを考え出そうとしています。比較的すぐにロードする必要があり、提供されたデータは提供されたデータのタイプと一致しないようですサンプル Web サイト ( http://www.iteminfo.com ) でデモを提供しています。いずれにせよ、私は彼らのプレゼンテーション構造を再利用しようとは考えていないので、それは論点ですが、私はサイトを閲覧して物事を構造化する方法についていくつかのアイデアを得ていました.

私が確信が持てないのは、データをこの形式で保持する必要があるかどうか、またはたとえば、自己参照関係を使用してマスター/部門/クラス/サブクラスを単一の「カテゴリ」テーブルに統合し、それを製品ブロック (製品ブロックは「カテゴリ」自体ではなく、特定のカテゴリに関連する製品のグループであるため、個別に保持する必要があります)。現在、製品ブロック テーブルはサブクラス テーブルを参照しているため、これらを統合すると「category_id」に変更されます。

私はおそらく、このデータを Ruby on Rails で利用する e コマース ストアフロントを作成する予定です (少なくとも、それは私の計画です)。考えすぎですが、申し訳ありませんが安全を確保したいと思います。以前のデータは本当に混乱しており、一貫性のない不正確なデータが原因で、会社は何万ドルもの売り上げを失っていました。また、Rails の規則から少し離れて、データベースが堅牢であり、制約が適用されるようにするつもりです (アプリケーション レベルでも行う予定です)。

このような状況にどのように対処しますか？テーブル構造を模倣するフラット ファイルにデータをロードする必要があることに注意してください (どの列がどの参照が設定されているかを示すドキュメントがあります)。それらを現在のように正規化したままにするか、統合する必要があるかを決定しようとしています。各メソッドが Rails を使用してサイトをプログラミングする方法にどのように影響するかを認識する必要があります。統合すると、単一のテーブルに本質的に 4 つの「レベル」のカテゴリが存在するためです。各レベル。サブクラス (製品ブロックに直接リンクする) を除いて、それらは行わないためそれらの下の次のレベルのカテゴリを表示する以外のもの。私は常に、このようなデータを処理するための「最善の」方法を失っています。