¿Por qué es obligatorio el prefijo de esquema (dbo) cuando llamamos a una función?

Cuando el usuario se asigna con el esquema predeterminado (dbo) y podemos seleccionar todas las tablas en [dbo] sin prefijar el esquema.

Podemos ejecutar procedimientos almacenados sin prefijo si está bajo el esquema predeterminado.

Dado eso, ¿por qué necesitamos prefijar una función con el esquema?

¡Gracias!

sql-server functions

— Rajesh Ranjan
fuente

Respuestas:

Entonces, ¿por qué podemos llamar a la función sin prefijo (esquema), creado bajo dbo?

Del libro de documentos en línea sobre UDF

Las funciones con valores escalares se pueden invocar donde se utilizan expresiones escalares. Esto incluye columnas calculadas y definiciones de restricciones CHECK. Las funciones con valores escalares también se pueden ejecutar utilizando la instrucción EXECUTE. Las funciones con valores escalares deben invocarse utilizando al menos el nombre de dos partes de la función .

Entonces, esto es básicamente una restricción establecida por el equipo de desarrollo de SQL Server y lo considero bastante correcto. Incluso si de alguna manera está permitido (solo por el bien de la conversación) todavía usaría el prefijo de esquema.

Siempre apoyo el uso del nombre de esquema, incluso si funcionaría sin agregarlo. Esta es la mejor práctica y todos los desarrolladores "buenos" la usan sin importar cuán redundante sea.

La otra razón por la que veo es que el motor de base de datos necesita algo para diferenciar entre funciones del sistema getdate ()y funciones definidas por el usuario. Si se le permite llamar a la función sin nombre de esquema, ¿cómo diferenciaría el motor de la base de datos entre la función creada por el usuario llamada Getdate o la función GETDATE () del sistema?

— Shanky
fuente

Entonces, ¿por qué es diferente con los SP? Como dijiste, puede ser para evitar nombrar colisiones. Acabo de crear un SP "create procedure sp_help as select getdate ()" en mi base de datos de usuario y cuando ejecuto con o sin esquema (dbo), SQL Server se refiere al SP del sistema. Por qué no ejecuta mi SP que he creado.

— Rajesh Ranjan

@rajeshRajan Dado que tiene sp_procname (prefijo su procedimiento con SP), esto obliga a SQL Server a buscar primero en la base de datos maestra para el plan compilado y dado que este proceso existe en la base de datos maestra, no se ejecutará, si no fuera para encontrar el proceso. en master entonces habría ejecutado el tuyo. Nunca debe crear procesos con el prefijo sp_ porque tiene problemas de rendimiento.

— Shanky

Creo que Shanky respondió la pregunta "por qué" directamente cuando mencionó que fue establecida por el equipo de desarrollo de SQL Server. Podrías preguntar por qué lo hicieron y por qué el comportamiento de las funciones es inconsistente con los procedimientos, pero la respuesta probablemente no importa demasiado.

— Michael J Swart

Por cierto, el impacto en el rendimiento de los procedimientos que comienzan con "sp_" no se puede medir. No ha sido un problema en años. El prefijo sp aún podría no ser una buena idea, pero el rendimiento no es la razón.

— Michael J Swart

La otra respuesta explica que esta es una restricción, pero no la razón.

El requisito no siempre es cierto. Los UDF escalares pueden ser EXECeditados y aún usar resolución implícita ( ejemplo )

Me imagino que esto es para evitar nombrar colisiones.

Si se permitiera hacer referencia a funciones sin esquema, entonces alguien que creó su propia función que se llamó crypt_gen_randomen 2000 o 2005 tendría problemas para actualizar a una versión posterior, ya que se convirtió en el nombre de una función incorporada en 2008.

No hay ambigüedad con el execuso, ya que las funciones integradas no se pueden llamar así.

— Martin Smith
fuente

— Rajesh Ranjan

@Rajesh. Los objetos que comienzan con sp_ tienen una carcasa especial para buscar siempre en la base de datos maestra / de recursos. Y está documentado que este prefijo debe evitarse. No existe tal convención para las funciones integradas.

— Martin Smith