問題タブ [rdbms-agnostic]

私は、RDBMS でどのようなビューが使用されているかについての一般的な考えを理解しようとしています。つまり、ビューとは何か、ビューを作成する方法を知っています。また、過去にそれらを何に使用したかも知っています。

しかし、ビューが何に役立つのか、ビューが何に役立たないのかを完全に理解していることを確認したいと思います。すなわち：

1. ビューは何に役立ちますか?
2. ビューを使用すべきではないのに、ビューを使用したくなるような状況はありますか?
3. テーブル値関数のようなものの代わりにビューを使用する理由、またはその逆を使用する理由は何ですか?
4. 一見しただけではわからない、ビューが役立つ可能性がある状況はありますか?

(記録のために、これらの質問のいくつかは意図的に素朴です。これは部分的に概念チェックです。)

ID を大まかに順番に保ちながら、INSERT ステートメントですぐに使用される ID 番号を生成する、DBMS に依存しない最良の方法は何ですか?

私は最近、SQLiteに適切なインデックスを与えることで、複雑なクエリを桁違いに高速化しました。このような結果から、JOINまたはORDERBY句に一般的に使用される他の多くのフィールドにインデックスを付ける必要があるかどうか疑問に思います。しかし、私は熱心になりすぎて逆効果になりたくありません。インデックスを作成しない理由がいくつかあるはずだと思います。そうしないと、すべてのフィールドがデフォルトでインデックスに登録されます。

この場合はSQLiteを使用していますが、もちろんDBMSに依存しないアドバイスも歓迎します。

私の会社では、Python ORM 用の Oracle のバックエンドの仕上げに取り組んでいます。私は、RDBMS が単純なものであっても、さまざまな方法で処理を行うことに驚いています。Oracle と他の RDBMS の違いについて多くのことを学びました。純粋な好奇心から、もっと学びたいと思っています。

あるプラットフォームから別のプラットフォームへの SQL の移植に関する一般的な「落とし穴」は何ですか?

回答ごとに 1 つの落とし穴だけにしてください。

SQL Server 2005 で、悪名高いエラー メッセージが表示されました。

テーブル YYY に FOREIGN KEY 制約 XXX を導入すると、サイクルまたは複数のカスケード パスが発生する可能性があります。ON DELETE NO ACTION または ON UPDATE NO ACTION を指定するか、他の FOREIGN KEY 制約を変更します。

現在、StackOverflow にはこのエラー メッセージに関するいくつかのトピックがあるため、解決策は既に得られています (私の場合はトリガーを使用する必要があります) が、なぜこのような問題が発生するのかについて興味があります。

私が理解しているように、彼らが回避したいシナリオは基本的に 2 つあります。サイクルと複数のパスです。循環とは、2 つのテーブルが相互にカスケードする外部キーを持つ場所です。OK、サイクルは複数のテーブルにまたがることもできますが、これは基本的なケースであり、分析が容易になります。

複数のパスは、TableA に TableB および TableC への外部キーがあり、TableB にも TableC への外部キーがある場合です。繰り返しますが、これは最低限の基本的なケースです。

これらのテーブルのいずれかでレコードが削除または更新されたときに発生する問題は見当たりません。確かに、どのレコードを更新/削除する必要があるかを確認するために、同じテーブルを複数回クエリする必要があるかもしれませんが、それは本当に問題なのでしょうか? これはパフォーマンスの問題ですか？

他の SO トピックでは、カスケードの使用を「危険」とラベル付けし、「カスケード パスの解決は複雑な問題です」と述べています。なんで？リスクはどこにありますか？問題はどこだ？

昨日、あるプロジェクトに取り組んでいるときに、奇妙な 1 対 1 の関係を思いついたので、これをどのように実装するのが最善か (明らかに、私たちは間違っていました :D)

A と B の 2 種類のエンティティが存在するという考え方です。これらはそれぞれ独立して存在することもできますが、それらの間にリンクを持つこともできます。リンクがある場合、それは 1:1 リンクであり、双方向で機能する必要があります。

ボトルとキャップのようなものです。それらは別々に存在できますが、一緒に結合すると、ボトルのキャップは 1 つだけになり、キャップは 1 つの (同じ) ボトルだけに取り付けられます。

正規化、データの整合性などに関するすべてのベスト プラクティスを念頭に置きながら、この関係をどのように実装しますか?

追加:言い忘れていましたが、それぞれに十数個のプロパティがあるため、フィールドの半分が NULL の同じテーブルにそれらを配置するのは、かなり厄介な解決策です。また、リンクはいつでも切断され、別のエンティティで再作成される可能性があります。

私はよくこのようなSQLを書く人を見かけます：

私自身は簡単に書いています：

私にとって「OUTER」キーワードはラインノイズのようなものです。追加情報は追加されず、SQLが乱雑になるだけです。私が知っているほとんどのRDBMSではオプションですらあります。それで...なぜ人々はまだそれを書いているのですか？癖ですか？移植性？（とにかくあなたのSQLは本当に移植可能ですか？）私が気付いていない他の何か？

私はオンライン調査に取り組んでいます。ほとんどの質問には、回答の 1 ～ 5 のスケールがあります。調査に質問を追加する必要がある場合は、適切なテーブルに INSERT を実行する単純な Web フォームを使用します。アンケートは新しい質問を投げかけています。新しいコードやデータベース構造の変更はありません。

さまざまなデータ型の回答を持つことができるアンケートの質問を追加するよう求められています。仕様は、調査を「構成可能」にすることであり、将来の任意の時点で、「{text answer question}、{1-5 question}、{true false question} を尋ねる新しい調査が必要です」と言ったときに、 , {回答として日付を含む質問}", データベース構造を変更せずにそれを行うことができます.

私はそれらの答えを保存する最善の方法を考えようとしていますが、私が思いついた方法はどれもややハックのようです.

はい/いいえまたは真/偽の答えを持つ質問もあれば、整数の答え (「この 1 か月でテクニカル サポートを利用した回数は?」) を持つ質問もあれば、日付、文字列、複数の数字を持つ質問もあります。単一の値を持つ選択肢、複数の値を持つ複数の選択肢など。または、特定の回答値によってサブ質問が表示される場合があります (「何があなたを失望させましたか...?」)。

簡単な解決策は、各質問を調査の列として、その回答を調査の列として、それを調査の列として質問するかどうかを指定することです。これは私には混乱のように感じます。これは 1 つの大きなテーブルです。あまり「関係的」ではありません。

ブレーンストーミング、私が思いつく「最良の」方法は、回答の種類ごとに異なる表を用意することですが、データの整合性の問題が発生しやすいと感じています。言い換えれば、私は持っているだろう

等

上記の問題の 1 つは、DDL だけでは、任意の質問に対して少なくとも 1 つだけの回答が存在することを保証できないことです。

もう 1 つの解決策は、質問テーブルに回答用のバイナリ列または文字列列を用意し、すべての回答を何らかの文字列またはバイナリ形式にエンコードして、回答列に格納することです。これにより、すべての質問に対して少なくとも 1 つだけの回答が得られますが、その後、SQL クエリの集計機能にアクセスできなくなります。これは、あまり「リレーショナル」なソリューションではないと思います。

ですから、上で概説したアイデアには問題があると思います。この問題を解決する「最善の」方法はありますか?

時間をかけて問題と私の考えを言語化した今、私が提起している大まかな問題は、「コーディングを行わずに任意の型のデータを保存したい...」ということのようです。絶望的？

私は MySQL を使用しているため、他の RDBMS にアクセスすることはできません。

この質問はこの投稿に関連しています： さまざまなデータ型の回答を使用した調査用のSQL設計

私は、ほとんどの質問に1〜5の回答のセットがある調査アプリを持っています。次に、数値、日付、文字列など、さまざまな回答タイプを持つ可能性のある質問を行う必要があります。スタックからの提案のおかげで、回答を格納するために文字列列を使用しました。いくつかの質問は多肢選択式であるため、テーブル「質問」とともに、質問に対する可能な回答のセットを含むテーブル「回答」があります。

さて、「該当するものをすべて選んでください」という質問に対する回答をどのように保存すればよいですか？「chosen_answers」などの子テーブルを作成する必要がありますか？または、回答テーブルに、回答者がその回答を選択したことを示す「選択済み」列を含める必要がありますか？

基本的に私は1対多のテーブルを持っています。大きい方のテーブルの列を小さい方のテーブルの結果セットに追加したいと思います。結果セットは小さいテーブルと同じサイズになりますが、ここでも、多面テーブルからの関連情報が含まれます。

1つの落とし穴：複合キーを確立することはできますが、多面テーブルには主キーが定義されていません（ここでも制約として存在しません）。