ORA-00907:falta el paréntesis derecho

ORA-00907:falta el paréntesis derecho

Este es uno de varios mensajes de error genéricos que indican que nuestro código contiene uno o más errores de sintaxis. A veces puede significar que literalmente hemos omitido un paréntesis derecho; eso es bastante fácil de verificar si estamos usando un editor que tiene un corchete de coincidencia capacidad (la mayoría de los editores de texto dirigidos a codificadores lo hacen). Pero a menudo significa que el compilador ha encontrado una palabra clave fuera de contexto. O tal vez sea una palabra mal escrita, un espacio en lugar de un guión bajo o una coma faltante.

Desafortunadamente, las posibles razones por las que nuestro código no se compila son prácticamente infinitas y el compilador no es lo suficientemente inteligente como para distinguirlas. Por lo tanto, arroja un mensaje genérico, ligeramente críptico, como ORA-00907: missing right parenthesis y nos deja a nosotros detectar el bombacho real.

El script publicado tiene varios errores de sintaxis. Primero discutiré el error que activa ese ORA-0097, pero deberá corregirlos todos.

Las restricciones de clave externa se pueden declarar en línea con la columna de referencia o en el nivel de la tabla después de que se hayan declarado todas las columnas. Estos tienen diferentes sintaxis; sus scripts mezclan los dos y es por eso que obtiene el ORA-00907.

La declaración en línea no tiene coma y no incluye el nombre de la columna de referencia.

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)

Las restricciones de nivel de tabla son un componente separado, por lo que tienen una coma y mencionan la columna de referencia.

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)

Aquí hay una lista de otros errores de sintaxis:

1. La tabla a la que se hace referencia (y la clave principal a la que se hace referencia o la restricción única) ya deben existir antes de que podamos crear una clave externa contra ellos. Por lo tanto, no puede crear una clave externa para HISTORYS_T antes de haber creado los ORDERS a los que se hace referencia mesa.
2. Ha escrito mal los nombres de las tablas a las que se hace referencia en algunas de las cláusulas de clave externa (LIBRARY_T y FORMAT_T ).
3. Debe proporcionar una expresión en la cláusula DEFAULT. Para las columnas FECHA que suele ser la fecha actual, DATE DEFAULT sysdate .

Mirar nuestro propio código con ojo frío es una habilidad que todos debemos adquirir para tener éxito como desarrolladores. Realmente ayuda estar familiarizado con la documentación de Oracle. Una comparación lado a lado de su código y los ejemplos en la Referencia de SQL lo habría ayudado a resolver estos errores de sintaxis en mucho menos de dos días. Encuéntralo aquí (11g) y aquí (12c).

Además de errores de sintaxis, sus scripts contienen errores de diseño. No se trata de fracasos, sino de malas prácticas que no deben convertirse en hábitos.

1. No ha nombrado la mayoría de sus restricciones. Oracle les dará un nombre predeterminado, pero será horrible y hará que el diccionario de datos sea más difícil de entender. Nombrar explícitamente cada restricción nos ayuda a navegar por la base de datos física. También conduce a mensajes de error más comprensibles cuando nuestro SQL activa una violación de restricción.
2. Nombra tus restricciones de manera consistente. HISTORY_T tiene restricciones llamadas historys_T_FK y fk_order_id_orders , ninguno de los cuales es útil. Una convención útil es <child_table>_<parent_table>_fk . Entonces history_customer_fk y history_order_fk respectivamente.
3. Puede ser útil crear las restricciones con declaraciones separadas. Crear tablas, luego claves primarias y luego claves externas evitará los problemas con el orden de dependencia identificado anteriormente.
4. Está intentando crear claves foráneas cíclicas entre LIBRARY_T y FORMATS . Puede hacer esto creando las restricciones en declaraciones separadas, pero no lo haga:tendrá problemas al insertar filas e incluso peores problemas con las eliminaciones. Debe reconsiderar su modelo de datos y encontrar una manera de modelar la relación entre las dos tablas para que una sea la principal y la otra la secundaria. O tal vez necesite un tipo diferente de relación, como una tabla de intersección.
5. Evite las líneas en blanco en sus guiones. Algunas herramientas los manejarán, pero otras no. Podemos configurar SQL*Plus para manejarlos, pero es mejor evitar la necesidad.
6. La convención de nomenclatura de LIBRARY_T es feo Intente encontrar un nombre más expresivo que no requiera un sufijo innecesario para evitar un conflicto de palabras clave.
7. T_CUSTOMERS es aún más feo, ya que es inconsistente con sus otras tablas y completamente innecesario, como customers no es una palabra clave.

Nombrar las cosas es difícil. No creerías las disputas que he tenido sobre los nombres de las mesas a lo largo de los años. Lo más importante es la consistencia. Si miro un diccionario de datos y veo tablas llamadas T_CUSTOMERS y LIBRARY_T mi primera respuesta sería confusión. ¿Por qué se nombran estas tablas con diferentes convenciones? ¿Qué diferencia conceptual expresa esto? Entonces, por favor, decida una convención de nomenclatura y apéguese a ella. Haga que los nombres de sus tablas sean todos singulares o todos plurales. Evite los prefijos y sufijos tanto como sea posible; ya sabemos que es una tabla, no necesitamos un T_ o un _TAB .