ORA-00907：右括弧がありません

ORA-00907：右括弧がありません

これは、コードに1つ以上の構文エラーが含まれていることを示すいくつかの一般的なエラーメッセージの1つです。文字通り右角かっこを省略したことを意味する場合があります。 マッチブラケットのあるエディタを使用しているかどうかを確認するのは簡単です。機能（コーダーを対象としたほとんどのテキストエディターにはあります）。しかし、多くの場合、コンパイラがコンテキスト外のキーワードに遭遇したことを意味します。または、スペルミスのある単語、アンダースコアの代わりのスペース、またはカンマの欠落である可能性があります。

残念ながら、コードがコンパイルされない理由として考えられるものは事実上無限であり、コンパイラーはそれらを区別するのに十分なほど賢くありません。そのため、ORA-00907: missing right parenthesisのような一般的な少しわかりにくいメッセージが表示されます。実際のブルーマーを見つけるのは私たちに任せます。

投稿されたスクリプトにはいくつかの構文エラーがあります。まず、ORA-0097をトリガーするエラーについて説明しますが、すべて修正する必要があります。

外部キー制約は、参照列に沿って、またはすべての列が宣言された後にテーブルレベルで宣言できます。これらの構文は異なります。スクリプトで2つが混在しているため、ORA-00907を入手できます。

インライン宣言にはコンマがなく、参照する列名が含まれていません。

CREATE TABLE historys_T    (
    history_record    VARCHAR2 (8),
    customer_id       VARCHAR2 (8) 
          CONSTRAINT historys_T_FK FOREIGN KEY REFERENCES T_customers ON DELETE CASCADE,
    order_id           VARCHAR2 (10) NOT NULL,
          CONSTRAINT fk_order_id_orders REFERENCES orders ON DELETE CASCADE)

テーブルレベルの制約は別のコンポーネントであるため、コンマを使用し、参照列について言及します。

CREATE TABLE historys_T    (
    history_record    VARCHAR2 (8),
    customer_id       VARCHAR2 (8),    
    order_id           VARCHAR2 (10) NOT NULL,
    CONSTRAINT historys_T_FK FOREIGN KEY (customer_id) REFERENCES T_customers ON DELETE CASCADE,   
   CONSTRAINT fk_order_id_orders FOREIGN KEY (order_id) REFERENCES orders ON DELETE CASCADE)

その他の構文エラーのリストは次のとおりです。

参照されるテーブル（および参照される主キーまたは一意性制約）は、それらに対して外部キーを作成する前に、すでに存在している必要があります。したがって、HISTORYS_Tの外部キーを作成することはできません。参照されるORDERSを作成する前テーブル。
一部の外部キー句（LIBRARY_T）で参照されているテーブルの名前のスペルを間違えましたおよびFORMAT_T ）。
DEFAULT句に式を指定する必要があります。通常は現在の日付であるDATE列の場合、DATE DEFAULT sysdate 。

自分のコードをクールな目で見ることは、開発者として成功するために私たち全員が習得する必要のあるスキルです。 Oracleのドキュメントに精通していると非常に役立ちます。コードとSQLリファレンスの例を並べて比較すると、2日以内にこれらの構文エラーを解決するのに役立ちます。ここ（11g）とここ（12c）で見つけてください。

構文エラーだけでなく、スクリプトには設計ミスが含まれています。これらは失敗ではありませんが、習慣になるべきではない悪い習慣です。

ほとんどの制約に名前を付けていません。 Oracleはそれらにデフォルトの名前を付けますが、それは恐ろしい名前になり、データディクショナリを理解しにくくします。すべての制約に明示的に名前を付けると、物理データベースをナビゲートするのに役立ちます。また、SQLが制約違反を引き起こしたときに、よりわかりやすいエラーメッセージが表示されます。
制約に一貫して名前を付けます。 HISTORY_T historys_T_FKと呼ばれる制約がありますおよびfk_order_id_orders 、どちらも役に立ちません。便利な規則は<child_table>_<parent_table>_fkです。。したがって、history_customer_fk およびhistory_order_fk それぞれ。
個別のステートメントを使用して制約を作成すると便利な場合があります。テーブル、主キー、外部キーの順に作成すると、上記で特定した依存関係の順序に関する問題を回避できます。
循環外部キーを作成しようとしています LIBRARY_Tの間およびFORMATS 。これは、別のステートメントで制約を作成することで実行できますが、実行しないでください。行を挿入するときに問題が発生し、削除するとさらに悪い問題が発生します。データモデルを再検討し、一方が親になり、もう一方が子になるように、2つのテーブル間の関係をモデル化する方法を見つける必要があります。または、交差点テーブルなど、別の種類の関係が必要な場合もあります。
スクリプトで空白行を避けてください。一部のツールはそれらを処理しますが、一部は処理しません。それらを処理するようにSQL*Plusを構成できますが、その必要性を回避することをお勧めします。
LIBRARY_Tの命名規則醜いです。キーワードの衝突を避けるために、不必要な接尾辞を必要としない、より表現力豊かな名前を見つけてください。
T_CUSTOMERS customersのように、他のテーブルとの整合性がなく、完全に不要であるため、さらに醜いです。キーワードではありません。

名前を付けるのは難しいです。あなたは私が何年にもわたってテーブル名について持っていた混乱を信じないでしょう。最も重要なことは一貫性です。データディクショナリを見て、T_CUSTOMERSというテーブルを見るとおよびLIBRARY_T 私の最初の反応は混乱でしょう。これらのテーブルに異なる規則で名前が付けられているのはなぜですか？どのような概念の違い これは表現しますか？ですから、命名規則を決めて、それを守ってください。テーブル名をすべて単数形またはすべて複数形にします。プレフィックスとサフィックスはできるだけ避けてください。テーブルであることはすでにわかっているので、T_は必要ありません。または_TAB 。