私はCJデイトのSQLとリレーショナル理論：正確なSQLコードを書く方法を読んでいます、そして彼は位置クエリが悪いと主張します—例えば、これINSERT：
INSERT INTO t VALUES (1, 2, 3)
代わりに、次のような属性ベースのクエリを使用する必要があります。
INSERT INTO t (one, two, three) VALUES (1, 2, 3)
タプル（行）は順序付けられていない属性のセット（列）であるため、最初のクエリがリレーショナルモデルと一致していないことを理解しました。最初のクエリのどこに害があるのか理解できません。誰かが私にこれを説明できますか？
最初のクエリは、テーブルスキーマが変更されるたびにほとんど壊れます。2番目のクエリは、列をそのまま残し、デフォルトのない列を追加しないスキーマ変更に対応します。
SELECT *クエリを実行してから、関心のある値を抽出するために位置表記に依存する人々は、同じ理由でソフトウェアメンテナンスのスーパーヴィランです。
列の順序はスキーマで定義されていますが、概念的に重要ではないため、通常は重要と見なされるべきではありません。
また、最初のバージョンを読んでいる人は誰でもスキーマを調べて、値が何を意味するのかを知る必要があることを意味します。確かに、これはほとんどのプログラミング言語で位置引数を使用するのと同じですが、SQLはこの点で少し異なっているように感じます-私は確かに2番目のバージョンをはるかに簡単に理解します（列名が賢明であると仮定します）。
この点に関して、私は理論的な概念についてはあまり気にしません（実際には、テーブルには定義された列の順序があります）。私が最初のものよりも2番目のものを好む主な理由は、抽象化レイヤーが追加されていることです。クエリを台無しにすることなく、テーブルの列を変更できます。
SQL クエリがテーブルの正確なレイアウトにできるだけ依存しないようにする必要があります。
最初のクエリは、フィールドが 3 つしかないテーブルに、その正確な順序で依存しています。テーブルに何らかの変更を加えると、クエリが壊れます。
2 番目のクエリは、これら 3 つのフィールドがテーブルに存在することだけに依存しており、フィールドの順序は関係ありません。クエリを中断せずにテーブル内のフィールドの順序を変更できます。また、null 値が許可されているか、デフォルト値がある限り、フィールドを追加することもできます。
テーブル レイアウトを頻繁に再配置することはありませんが、テーブルにフィールドを追加することはよくあります。
また、2 番目のクエリはより読みやすくなっています。クエリ自体から、レコードに入力された値が何を意味するかを知ることができます。
まだ言及されていないことは、多くの場合auto_increment、値を割り当てる (または同様のもの) を使用して、PK として代理キーを使用することです。最初のものでは、そこに何かを指定する必要があります— しかし、それが使用されない場合、どのような値を指定できますか? NULLオプションかもしれませんが、PK が に設定されることを考えると、それは実際には適合しませんNOT NULL。
しかし、それとは別に、「特定のスキーマにロックされている」全体がはるかに重要な理由です.IMO.
SQL では、INSERT ステートメントと SELECT ステートメントの両方で列の名前を指定するための構文が提供されます。次の理由により、これを使用する必要があります。
私は UPDATE のような構文を使用することを好みます。
INSERT t SET one = 1 , two = 2 , three = 3
これは、両方の例よりもはるかに読みやすく、維持しやすいものです。
長期的には、テーブルにもう 1 つの列を追加すると、列のリストを明示的に指定しない限り、INSERT は機能しません。誰かが列の順序を変更した場合、INSERT は暗黙のうちに値を間違った列に挿入することに成功する可能性があります。
もう1つ追加します。2番目のクエリは、テーブルが変更される前であっても、元々エラーが発生しにくいということです。なぜ私はそれを言うのですか？seocndフォームを使用すると、挿入テーブルの列とvalues句またはselect句のデータが実際に正しい順序であるかどうかを視覚的に確認できます（クエリを作成するときに必要です）。そうしないと、誤って社会保障番号をHonorariaフィールドに入力し、スピーチに必要な金額の代わりにSSNをスピーカーに支払うことになります（例はランダムに選択されていませんが、そのおかげで実際に発生する前にキャッチした場合を除きます）目視検査！）。