¿Dónde almacena normalmente sus constantes PL/SQL? En el nivel del cuerpo del paquete? En la especificación? También he visto a algunas personas con constantes en un paquete especializado solo por constantes. ¿Cuáles son las mejores prácticas en esta área?Donde mantener las constantes PL/SQL?
Gracias.
Una desventaja de tener constantes en un cuerpo de paquete o especificación es que al volver a compilar el paquete, cualquier sesión de usuario que tuviera el estado del paquete en la PGA obtendría ORA-04068. Por esta razón, en un entorno de desarrollo grande, adoptamos la convención de tener un paquete separado de solo especificación para mantener las constantes (y los globales del paquete, si corresponde) para cada paquete. Luego, impondríamos una regla que establezca que a estos paquetes de especificaciones solo se les permite hacer referencia a ellos en su paquete "propietario", que aplicamos en la revisión del código. No es una solución perfecta, pero funcionó para nosotros en ese momento.
Por la misma razón, nunca recomendaría one-constant-package-to-rule-them-all porque cada vez que alguien necesita introducir una nueva constante, o modificar una existente, todas las sesiones de usuario obtienen ORA- 04068.
En muchos casos, desea mantenerlos en la especificación para que otros paquetes puedan usarlos, especialmente como parámetros al llamar funciones y procedimientos de su paquete.
Solo cuando desee mantenerlos en privado para el paquete, debe colocarlos en el cuerpo.
Tener un paquete solo para constantes puede ser una buena idea para las constantes que no están relacionadas con ningún fragmento de código en particular, pero son relevantes para todo el esquema.
Preferiría que las constantes estuvieran, por defecto, en el cuerpo del paquete a menos que use la constante como valor de parámetro para uno de sus procedimientos/funciones de paquete público o como un valor de retorno para sus funciones.
El problema al poner sus constantes en la especificación del paquete es que si necesita cambiar el tipo de la constante, otros paquetes pueden fallar que usan la constante porque estaba allí. Si la constante era privada en primer lugar, no es necesario realizar un análisis de impacto para cada cambio.
Si necesita almacenar contants como lenguaje predeterminado o cosas por el estilo, entonces encapsularé esos contants en funciones como get_default_language etc. y mantendría las constantes en privado.
Me preocuparía tener "un paquete para regular las constantes" porque el estado del paquete - constantes, variables y código - se almacenan en caché en la PGA del usuario en la primera invocación de cualquier variable o paquete público. Una constante de paquete, si es pública, debe tener un alcance para el paquete y utilizarse solo por los métodos del paquete.
Una constante cuyo alcance abarca paquetes debe estar en una tabla de códigos con una descripción, unida según sea necesario. Las constantes no son y las variables no, después de todo. Tener una tabla de "constantes" de pares clave-valor los hace públicos, y hace que cambiarlos dinámicamente sea posible.
Para nuestra aplicación, todas las constantes están en una tabla. Una función simple se usa para extraerlos. No hay problema con la recompilación, ORA-04068, ...
Entonces, en realidad no son "constantes", ¿o sí? :-) – ObiWanKenobi
_ "La constante de un hombre es la variable de otro hombre". _ - Alan Perlis – user272735
La mejor opción en mi opinión. Almacene la "constante" en una tabla y cree una función genérica para obtener los valores.No 04068
Epílogo de la exhaustividad: la mejor práctica es definir lo más cercano posible a su uso: si la constante solo se utiliza en un procedimiento, defínala en ese procedimiento; si la constante solo se usa en un cuerpo de paquete, defínalo en el cuerpo del paquete (excepto por el problema ORA-04068 mencionado anteriormente, que se convierte en un problema menor en 11gR2, se debe mencionar, si se usan las ediciones). –