問題タブ [database-design]

データベース内のトリガーまたは制約でビジネス クリティカルなロジックを使用する必要があるかどうかを調べようとしています。
これまでのところ、トリガーにロジックを追加しました。これにより、次に何が起こるかを制御できるようになり、ユーザーを混乱させる可能性のあるエラーの代わりにカスタム ユーザー メッセージを提供できるようになります。

トリガーよりも制約を使用することで顕著なパフォーマンスの向上はありますか?また、使用するものを決定するためのベスト プラクティスは何ですか?

私は、購入したエディション、購入した追加機能などに応じて、各顧客の構成が異なるSaaSアプリケーションに取り組んでいます。たとえば、顧客のカスタムレポートは3つに制限されている場合があります。

明らかに、この構成をデータベースに保存したいのですが、最善の方法がわかりません。将来的には、データベーススキーマを変更せずに機能を追加できるようにしたいので、構成オプションごとに列を持つ単一のテーブルは意味がありません。

可能なオプションは、顧客ごとに1つのエントリがあり、その顧客の構成全体を含むXMLフィールドを持つテーブルですが、XMLスキーマが変更されて機能が追加されると、複雑さが増します。

キーと値のペアを持つテーブルを使用し、すべての構成設定を文字列として保存してから正しいデータ型に解析することもできますが、文字列構成オプション、整数構成オプション、等

人々が使用しているこのタイプのシナリオに適したパターンはありますか？

レストランの配達情報を含むデータウェアハウスを構築しています。データはSQLServer2005に格納されてから、SQL Server AnalysisServices2005キューブに配置されます。

配信情報は、次の表で構成されています。

FactDeliveres

• BranchKey
• DeliveryDateKey
• プロダクトキー
• InvoiceNumber（DD：縮退ディメンション）
• 量
• 単価
• ラインコスト

ノート：

• FactDeliveresの粒度は、請求書の各行です
• 製品ディメンションには、サプライヤー情報が含まれます

そして問題：ファクトテーブルの主キーがありません。主キーは、各配信とProductKeyを一意に識別するものである必要があります。しかし、配達を一意に識別する方法はありません。

ソースOLTPデータベースには、すべての配信に固有のDeliveryIDがありますが、これはユーザーにとって意味のない内部IDです。InvoiceNumberはサプライヤーの請求書番号です。これは手動で入力されるため、重複します。

キューブでは、FactDeliveresのInvoiceNumberフィールドのみに基づいてディメンションを作成しました。つまり、InvoiceNumberでグループ化すると、（誤って）同じInvoiceNumberを持っているという理由だけで、2つの配信が組み合わされる可能性があります。

DeliveryID（DeliveryKeyと呼ばれる）を含める必要があると感じましたが、その方法がわかりません。

私もそうです：

1. これをInvoiceNumberディメンションの基になるキーとして使用しますか？
2. 新しい配信があるたびに増加するDimDeliveryを作成しますか？これは、DeliveryDate、Supplier、InvoiceNumberなど、一部の属性がFactDeliveriesから出てDimDeliveryに入るということを意味している可能性があります。

結局のところ、私はあなたに尋ねることができます：ソースデータベースに次の情報がある場合、Deliveriesキューブを作成するにはどうすればよいですか？

DeliveryHeaders

• DeliveryID（PK）
• 配送日
• サプライヤーID（FK）
• InvoiceNumber（手動で入力）

配達の詳細

• DeliveryID（PK）
• ProductID（PK）
• 量
• 単価

約 1 年前、私は Scott Ambler のRefactoring Databases: Evolutionary Database Designを取り上げました。私は、TDD でコードを開発できるのと同じように、データベースを (少なくとも) 単体テストでカバーするか、スキーマに変更を加える前にデータベース テストを作成して、データベースの作業を行う必要があるという考えに納得しました。 TDDスタイルでも。

私はこのアイデアが本当に好きで、これをしばらくの間手動で行ってきました (OK、時々実行します)。たまたまデータベースに接続し、その構造を特定のスキーマ ファイルに対してチェックする通常の単体テストを作成するだけです。しかし、このプロセスを自動化するのに役立つ優れたデータベース変更管理ツールキットは見つかりませんでした。誰か知っていますか？

900x100要素の2D配列をデータベースに保存しようとしています。アレイの効率的なリコールと比較が重要です。[A、x、y、A（x、y）]のようなスキーマを持つテーブルを使用して、単一の配列が90,000レコードを危険にさらすようにすることができます。これは、配列を格納するための〜ok〜テーブル設計のように見え、単一要素の効率的なリコールを提供しますが、配列全体の非効率的なリコールを提供し、非常に非効率的な配列比較を行います。

テーブルのデザインをこのように残して、コードで配列を作成して比較する必要がありますか？または、データベースのみの操作を使用して効率的な配列比較を取得できるように、テーブルを構造化するためのより良い方法はありますか？

ありがとう

次のテーブルを含むアプリを作成しています: (1) employee_type、(2) employee、(3) employee_action。

Employee_action は employee への外部キーであり、予想どおり、何が起こったかの説明とイベントの日付が含まれています。

ただし、従業員は時間の経過とともにタイプを変更できます (昇進、降格、異動など)。私のスキーマがこれと同じくらい単純である場合、John が 10 年前にピザを配達していたとき、John が会社の CEO であったことを示す履歴レポートを生成できます。

従業員がアクションを実行した時点で特定の一連の特性を持っていたという事実を保存するための最良の方法は何ですか?

ここで私の問題を簡単に述べています。私は 3 つよりも多くのテーブルを持っており、私が心配しているのは従業員の位置だけではありません。すべてを非正規化して、可能なすべての従業員フィールドを含む履歴テーブルを作成することは、私にとって選択肢ではありません。

ありがとう、これが明確であることを願っています。

私は Flex ベースの消費者向けWeb サイトを持っています。ここでは、ランダムな基準やその他の基準に基づいてさまざまなルック アンド フィール タイプの設定を変更し、これらを追跡して最も多くの売上を達成したいと考えています。

たとえば、ホームページを完全に切り替えて、人々がどこから来たかによって異なるものを表示するかもしれません。特定の機能を表示または非表示にしたり、特定のテキストを変更したりすることがあります。私が変更する可能性のあるものはまだ定義されておらず、非常に複雑になる可能性があります。

最も柔軟なデータベース スキーマを設計したいのですが、効率的で検索しやすいものでなければなりません。現在、個々の訪問者に関する情報を含む「SiteVisit」テーブルがあります。

各設定の列を持つ単一のテーブルと、キーと値のペアのみを含むテーブルとの間で適切なバランスを見つけたいと考えています。

助言がありますか？

現在、新しいデータベースを設計しています。学校では、各テーブルに主キーを配置することを常に学びました。

PK の代わりに一意の制約 (一部のデータベースの一意のインデックス) を使用する方が良いという記事/ディスカッション/ニュースグループの投稿をたくさん読みました。

あなたの視点は何ですか？

複合キーは一意のオブジェクトIDフィールドを使用するよりもはるかに理想的であり、データベースを構築するときは、単一​​の一意のIDを主キーとして使用しないという考えで構築されたデータベースを継承しました。このデータベース用にRailsフロントエンドを構築していたため、Railsの規則に準拠させるのに苦労しました（ただし、カスタムビューといくつかの追加のgemを使用して複合キーを処理することは可能でした）。

それを書いた人からのこの特定のスキーマ設計の背後にある理由は、データベースが非効率的な方法でIDフィールドを処理する方法と関係があり、インデックスを構築するときに、ツリーの並べ替えに欠陥があります。この説明には深みがなく、私はまだ概念に頭を悩ませようとしています（私は複合キーの使用に精通していますが、100％の時間ではありません）。

誰かが意見を提供したり、このトピックにさらに深みを加えることができますか？

緯度と経度のペアで計算を実行することを念頭に置いて、MySQLデータベースでの使用に最適なデータ型はどれですか？