問題タブ [relational]

オブジェクト リレーショナル マッパーや、インピーダンスの不一致を回避する最善の方法に関する情報はたくさんありますが、オブジェクト データベースを使用する場合、これらはすべて問題になるようです。私の質問は、なぜこれがより頻繁に使用されないのですか? それはパフォーマンス上の理由によるものですか、それともオブジェクト データベースによってデータがアプリケーションの所有物になるためですか、それとも何か別の理由によるものですか?

それで、私は MIT の OpenCourseWare から Discrete Math コースを受講していますが、疑問に思っています...関係とグラフの関係はわかりますが、それを「所有」するには十分ではありません。私は単純なステート マシンを SQL にも実装したので、関係とセットがどのように完全に適用されるかについてのより厳密な研究ではなく、グラフをかなりよく理解しています。すぐには理解できないものをざっと見て、もっと学んだときに戻ってくるというYeggeの一連の思考に従うべきですか？日々作成しているグラフ構造をよりよく分析できるようになりたいと思っています (面白そうです)。また、今すぐ貴重な情報を逃さないようにしたいと思っています。

（編集：さまざまな集合と関係のプロパティがグラフ理論などにどのように関連しているか、および基本的なグラフ理論が集合/関係にどのように関連しているかについて、より良いアイデアを得たいと思います。）

これについてもっと学ぶことができる良いリソースはありますか? 重要な場合に備えて、Rosen の Discrete Mathematics and Its Applications の第 5 版を使用しています。

ありがとう！

次の例に示すように、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 には当てはまりません。

1995年にDate'sとDarwenの「 TheThirdManifesto」が最初に発行されてから、10年以上が経過しました。

今日のデータベースの世界では、リレーショナルスクールの考え方はどこにありますか？マニフェストのアイデアが主流のソフトウェア開発とデータ管理の慣行を変えたという証拠はありますか？彼らは新しいデータ管理製品の作成を促進しましたか？これらの製品は商業的に成功していますか？

bigtabe/simpledb データベースとリレーショナル データベースはいつ使用しますか?

いくつかの関連オブジェクトを含む中間層と、いくつかの DataTable およびリレーションシップを持つ DataSet を使用するデータ層があります。

オブジェクトの 1 つ (親オブジェクト) で Save メソッドを呼び出し、そのプライベート変数データを DataRow に変換して DataTable に追加したいと考えています。プライベート変数データの一部は、実際には他のオブジェクト (子オブジェクト) であり、それぞれ独自の Save メソッドを呼び出し、独自の変数データを保持する必要があります。

これを「レース」するにはどうすればよいですか？DataSet のどの部分を ParentObject でインスタンス化する必要があり、ChildObjects に渡してデータセットに追加できるようにする必要があるか?

また、2 つのテーブルの関係を結び付けるにはどうすればよいですか?

Order OrderDetail 関係について私が見た例では、OrderRow と OrderDetailRow を作成し、次に OrderDetailRow.SetParentRow(OrderDetail) を呼び出します。

私の Order と OrderDetail (例の名前付けを使用) は別のクラスにあり、例では Big Honking Method ですべてが発生しているため、これがうまくいくとは思いません。

ありがとう、キース

多くのデータベース システムでは、テーブルやフィールドのコメントや説明を許可していません。では、テーブルやフィールドの目的を文書化するには、適切な命名規則を使用することは別として、どうすればよいでしょうか?

(今のところ、データベース内のすべてのテーブル、フィールド、および関係の完全な意味を文書化するには、「優れた」テーブル名とフィールド名では不十分であると仮定しましょう。)

多くの人がデータベースを視覚化するために UML ダイアグラムを使用していることは知っていますが、フィールド コメントを含む UML ダイアグラムを見たことはほとんどありません。.sqlただし、ファイル内でコメントを使用した経験は豊富です。このアプローチの欠点は.sql、データベース構造が時間の経過とともに変化するにつれて、ファイルを手動で最新の状態に保つ必要があることですが、そうする場合は、バージョン管理下に置くこともできます。

私が見た他のいくつかのテクニックは、データベースの構造と関係を説明する別のドキュメントと、ORM コードまたはその他のデータベース マッピング コード内の手動で維持されたコメントです。

過去にこの問題をどのように解決しましたか？どのような方法が存在し、それらに関連するさまざまな長所と短所は何ですか? 「完璧な世界」でこれをどのように解決しますか?

アップデート

他の人が指摘しているように、一般的な SQL エンジンのほとんどは実際にコメントを許可しています。これは素晴らしいことです。奇妙なことに、人々はこれらの機能をあまり使用していないようです。少なくとも、私が過去に関わったプロジェクトではそうではありません。

リレーショナル データベースの SQL 実装は、現在の形で約 25 年間 (System R と Ingres 以来) 存在しています。主な (緩く準拠している) 標準でさえ ANSI-92 (後で更新されましたが) は 15 年前のものです。

過去 10 年ほどの間に SQL ベースのデータベースでどのような革新があったと思いますか? 特に、OLAP、Columnar、およびその他の非リレーショナル (または少なくとも非 SQL) の革新を除外しています。「アプリケーション サーバー」タイプの機能とバンドル (レポート ツールなど) も除外したい

基本的なアプローチはかなり静的なままですが、次のように考えることができます。

• 可用性
• より大きなデータ セットを処理する機能
• メンテナンスと構成の容易さ
• より高度なデータ型 (blob、xml、unicode など) のサポート

他に考えられるものはありますか？

私は3つのテーブルを持っています（アーカイブには多くのセクションがあり、セクションは多くのアーカイブに属している可能性があります）：

• archive

  • id PK
  • description

• archive_to_section

  • archive_id PK FK
  • section_id PK FK

• section

  • id PK
  • description

特定のアーカイブIDに属するすべてのセクションを一覧表示するSQLはどのようになりますか？

私はSQLを学んでいます。私が読んだことから、私は参加、または組合が必要だと思いますか？参考までに、私はpostgresを使用しています。

[編集]これはエイリアスなしで書かれたgdean2323からの答えです：

データベース担当者が正規化について話し続けるのはなぜですか?

それは何ですか？それはどのように役立ちますか？

データベース以外にも適用されますか?