問題タブ [database-design]

状況：非正規化されたテーブルが多数ある大規模なデータベースがあります。サマリーテーブルの同期を維持するために、データを再サマリーする必要があることがよくあります。データを最新の状態に保つために計算列を使用することについて、話し合いました。トリガーについても話しましたが、それは別の議論です。

サマリーテーブルでは、標準IDと標準の説明がテーブルに格納されるようにテーブルを非正規化しました。これは本質的に、テーブルが十分な頻度で再要約されることを前提としているため、標準の説明を変更すると、要約テーブルでも変更されます。悪い仮定。

質問：サマリーテーブルの標準の説明を、標準のテーブルから標準の説明を選択する派生/計算列にした場合はどうなりますか？100,000〜500,000行のテーブルに計算列をドロップすると、パフォーマンスが大幅に低下しますか？

私は最近、あまりうまく設計されていないデータベースを維持する仕事を引き継ぎました。デザイナーは質問をすることができません。そして、近い将来、さらにいくつかの道が開かれます。

視覚的な補助やデータベース図を使用せずに、テーブル間の関係を理解し​​ようとするのは困難でした。

これにはどのツールが推奨されるのか疑問に思いました。私はVisioについて知っていますが、そこにいくつかの優れたオープンソース/フリーウェアアプリケーションがあることを望んでいました。データベースを変更するのに必要ありません。それを読んで、ある種の視覚的な補助を作成して、物事がどのようにレイアウトされているかを理解し、データがどのように関連するかについてデザイナーが何を考えているかを理解しようとします。

追加の回答データ：SchemaSpyは私が探していたようなものでしたが、昔はコマンドラインで多くのことをしていなかったので、SchemaSpyGUIを使用することにしました。また、Javaをあまり使用しないため、慣れるための構成もいくつかありましたが、最終的には私が探していたものになりました（VisioのER図のオープンソースの置き換え）。

これは、私が何年にもわたって複数の場所で見たシナリオです。他の誰かが私よりも優れたソリューションに出くわしたかどうか疑問に思っています...

私の会社は比較的少数の製品を販売していますが、販売する製品は高度に専門化されています (つまり、特定の製品を選択するには、その製品に関するかなりの数の詳細を提供する必要があります)。問題は、特定の製品を選択するために必要な詳細の量は比較的一定ですが、必要な詳細の種類は製品によって大きく異なることです。例えば：

製品 X には、(仮説的に) 次のような識別特性がある可能性があります。

• '色'、
• '素材'
• 「平均故障時間」

ただし、製品 Y には特性がある可能性があります

• '厚さ',
• '直径'
• '電源'

製品 X と製品 Y の両方を利用する注文システムを作成する際の問題 (とにかくそのうちの 1 つ) は、ある時点で注文明細が「販売」しているものを参照する必要があることです。製品 X と製品 Y は 2 つの異なるテーブルで定義されているため、幅広いテーブル スキームを使用した製品の非正規化はオプションではありません (製品定義は非常に深い)。注文入力、編集、レポート作成が実用的です。

過去に試したこと

• 製品 X と製品 Y に共通の列を持つ「製品」という名前の親テーブルを作成し、次に「製品」を OrderLine テーブルの参照として使用し、製品 X のテーブル間のプライマリ サイドとして「製品」との FK リレーションシップを作成します。これは基本的に、'Product' テーブルを OrderLine とすべての異なる製品テーブル (例: Products X と Y) の両方の親として配置します。注文入力には問題なく機能しますが、「製品」レコードは、「製品」をより詳細な子である製品 X または製品に結合する方法を決定するために、製品の種類を追跡する必要があるため、注文のレポートまたは編集で問題が発生します。 Y.利点: キー関係が保持されます。 短所: レポート、注文明細/製品レベルでの編集。
• 注文明細レベルで「製品タイプ」列と「製品キー」列を作成し、いくつかの CASE ロジックまたはビューを使用して、明細が参照するカスタマイズされた製品を決定します。これは項目 (1) に似ていますが、共通の「製品」テーブルはありません。注文明細行とその製品定義の間の外部キーが完全になくなるため、これはより「迅速かつ汚い」ソリューションだと思います。利点: 迅速な解決。 短所: (1) と同じですが、RI が失われます。
• 共通のヘッダー テーブルを作成し、カスタマイズされた属性 (OrderLine [n] <- [1] Product [1] <- [n] ProductAttribute) のキーと値のペアを使用して、製品定義を均質化します。 利点: キー関係が保持されます。製品の定義に曖昧さはありません。 短所: レポート (属性を含む製品のリストの取得など)、属性値のデータ入力、パフォーマンス (製品属性の取得、製品属性の挿入または更新など)

他の誰かが別の戦略を試して成功した場合は、ぜひ聞いてみたい.

ありがとうございました。

SQL Server のフルテキスト インデックスで複数のテーブルにインデックスを作成できないことはわかっています。しかし、全文索引を実装したいテーブルにリレーションシップがあります。

以下の3つの表を見てください...

Attributes テーブルと AttributeTypes テーブルには、ビルド中のアプリケーション全体でドロップダウン リストで使用できる値が保持されます。たとえば、「黒」、「青」、「赤」などの属性を持つ「車両の色」の属性タイプ...

ユーザーが「ブルー フォード マスタング」を検索しようとすると、問題が発生します。では、Vehicle のようなテーブルがかなり大きくなることを考えると、最善の解決策は何でしょうか?

「FK Atr VehicleColor」に加えて、ドロップダウンで選択されたもののテキスト値を保持する「Veh Color」である「Vehicle」テーブルに別のフィールドを作成する必要がありますか?

または、「FK Atr VehicleColor」を完全に削除して、「Veh Color」を追加しますか? ドロップダウンが更新フォームに取り込まれているときに、「Veh Color」のテキスト値を使用して「Atr Name」と照合できます。このアプローチでは、属性がデータベースから削除された場合に対処する必要があります。

-- 注: 2 つのアンダースコアの間のすべてがイタリック体であるため、コード ビューの外ではアンダースコアを使用できませんでした。

(データベース スキーマのバージョン管理とは関係ありません)

多くの場合、データベースとやり取りするアプリケーションには、多くのテーブルのデータで構成されるドメイン オブジェクトがあります。アプリケーションが、CVS の意味で、これらのドメイン オブジェクトのバージョン管理をサポートするとします。

任意のドメイン オブジェクトについて、この要件を処理するデータベース スキーマをどのように設計しますか? 共有する経験はありますか？

次の例に示すように、is-a 関係を表す明確な方法があるかどうか疑問に思っていました。

このDBには、映画、ゲーム番組、ドラマの3種類の番組の録画時間が格納されています。オブジェクト指向の意味では、これらのそれぞれがプログラムです。これらのサブクラスには、それぞれ異なるプロパティがあります。テーブルは次のとおりです (fk プレフィックスは外部キーを示します)。

ムービー
ID
名
fkDirector

gameShow
ID
名
fkHost
fkContestant

ドラマ
ID
名

OO 用語では、レコード テーブルは次のようになります。

record
id
fkProgram
startTime
endTime

通常の形式に違反せずにこれを行う唯一の方法は、 recordMovie、recordGameShow、およびrecordDramaという 3 つのレコード テーブルを用意することです。

データベースの正規化の原則に違反することなく、これらのテーブルを 1 つに統合する方法はありますか?

アイデアを説明するために、いくつかの動作しない例を次に示します。

番組
ID
fkMovie
fkGameShow
fkDrama

このテーブルには null が含まれるため、第 1 正規形に違反します。行ごとに、3 つのエントリのうちの 1 つだけが非 null になります。

program
id
fkSpecific ← fkMovie または fkGameShow または fkDrama
fkType ← 調べるテーブルを示します

ここでは、fkSpecific が 3 つのテーブルのいずれかを指す可能性があるため、参照整合性を強制することはできません。

ここにテーブルを 1 つではなく 3 つ持つことによるオーバーヘッドを節約しようとしています。おそらく、これは単に RDB には当てはまりません。

SQL Server、PostgreSQL、MySQL をサポートする手頃な価格の SQL モデリング ツールをお勧めしてもらえますか? ライセンス範囲ごとに最大 300 ドルを検討しています。回答ごとに 1 つのツールでお願いします。

ありがとう！

私が参加しているいくつかのWebアプリケーションプロジェクトでは、クライアントが独自のフォームを作成できるように要求しています。フォーム定義をどのように保存するか、そしてユーザーが入力した値をそれらのカスタムフォームにどのように保存するかという問題が発生します。

私はそれが2つの方法で行われるのを見てきました：

1. クライアントがフィールドの数と、それらのフィールドに関連付けられているラベルのみを定義すると仮定します。4つのテーブルを含むソリューションにたどり着くことができます。 FormDefinition、、、、。FormFieldDefinition_ FormInstances_ FormFieldValuesクライアントはとに変更を加えFormDefinition、FormFieldDefinitionWebアプリはその情報を使用してHTML Webフォームをレンダリングします。このフォームで、Webサイト訪問者（エンドユーザー）がフォームを送信します。このフォームで、新しい行FormInstancesが作成され、値がに保存されます。FormFieldValuesテーブル。

   の行FormDefinitionはフォームを定義しますform definition ID = 2, form title = 'Car Registration Form'。の行は、のフォームFormFieldDefinitionのフィールドを定義します。行は、ユーザーが入力した各フォームのインスタンスです。そして、の行はユーザーによるエントリです。FormDefinitionfield definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'FormInstancedefinition id = 2, date_entered = '2008-09-24'FormFieldValuesfield definition = 7, value = 'Tiburon'

   残念ながら、の値列はFormFieldValues、クライアントがWebフォームで指定できる最大サイズのchar型でなければならないことを意味します...フォーム定義が変更されると、古いデータの管理が困難になります。ただし、ユーザーエントリはクエリ可能です（別のピボット質問と同様に、フォームIDを指定してユーザーエントリを一覧表示する簡単なクエリを作成しました）。

2. 4つのテーブルを使用する代わりに、フォーム定義とユーザーのフォームエントリをXML（またはYAMLなど）にシリアル化し、それをテキストとして保存することもできます。利点は、フォームがデータベースで人間が読める形式であることです。欠点は、XMLの解析によりアプリケーションのオーバーヘッドが増加し、SQLの観点からデータベースのクエリがはるかに少なくなることです。

私の本当の質問は、このデータベースモデルは何と呼ばれているのかということです。（だから私はこの問題をグーグルで検索することができます。）しかし、私は答えを決めるでしょう：どちらがより良い実装ですか、それともそこにもっと良い（または同じくらい良い）実装がありますか？

後で別の言語に変換する必要があるデータを格納するテーブルを設計しようとしています。これに関する「ベストプラクティス」またはガイドラインを提供できる人はいますか?

ありがとう

私たちの製品の私の担当分野のテーブルは、複数の直交インデックスを持っていると批判されています。

直交指数とは何ですか?
なぜ悪いのですか？
どうすれば状況を回避できますか？

--更新
-- アプリケーションはデータベースに依存しないため、バックエンド データベース エンジンは必ずしもここでは関係ありません。しかし、それが役立つ場合、オラクルは 1 つの可能性です。

問題のテーブルは、財務分析には使用されません。