El dbo. prefijo en nombres de objeto de base de datos, ¿puedo ignorarlo?

Question

Estoy buscando una política por defecto de rendimiento para tratar con el prefijo .dbo.

que se dan cuenta de que la DBO. el prefijo es más que ruido sintáctico, sin embargo, he superado los últimos 8 años de desarrollo basado en MS omitiendo escribir el dbo. prefijo e ignorando su función.

Aparte de un problema de rendimiento con los bloqueos de compilación de proc almacenados, ¿hay una desventaja de omitir el tipeo ".dbo" en SQLqueries y procedimientos almacenados?

Otros antecedentes: Todo mi desarrollo es de nivel medio web basado en seguridad integrada basada en una cuenta de servicio de nivel medio.

Answer 1

[dbo]. [Xxx]

El motor de SQL Server siempre analizar la consulta en pedazos, si no se utiliza el prefijo definitivamente en marcha la búsqueda de objeto en nombre similar con diferentes usuarios antes de que se utiliza [ dbo]. Le sugiero que siga el mecanismo de prefijo no solo para satisfacer las mejores prácticas, sino también para evitar problemas técnicos de rendimiento y hacer que el código sea escalable.

No sé respondí a su pregunta, pero estos son sólo mi cuota de conocimiento

Answer 2

mayoría de las veces se puede pasar por alto. A veces tendrás que escribirlo. A veces, cuando se tiene que escribirla solo tendrá que teclear un extra '':

SELECT * FROM [LinkedServer].[Database]..[Table] 

que necesitará para empezar a ver para que si empezar a usar esquemas adicionales mucho más, en la que podría tener dos esquemas en la misma base de datos que ambas tienen tablas con el mismo nombre.

Answer 3

"sin embargo, pasé los últimos 8 años de desarrollo basado en MS omitiendo escribir dbo. Prexfix e ignorando su función".

Esta es su respuesta. Si su base de datos funciona bien, está bien. Las mejores prácticas no reemplazan las pruebas reales en su sistema real. Si su rendimiento es bueno y el mantenimiento está bien, es mejor que pase su tiempo en otro lugar donde pueda obtener mejores resultados por su dinero proverbial.

Answer 4

Después de trabajar en el mundo de Oracle, aconsejaría evitar omitir la declaración de esquema. Recuerde ahora que las versiones de SQL Server posteriores a 7.0 admiten varios esquemas por base de datos; es importante distinguirlos para asegurarse de que está utilizando las tablas adecuadas.

Si puede asegurarse de que nunca tendrá dos espacios de nombres de esquema separados por base de datos, puede ignorarlo. El dbo. el prefijo no debe hacer nada para afectar el rendimiento por sí mismo: el análisis es una parte tan pequeña de la consulta SQL como para ser insignificante.

Answer 5

El problema principal no es la seguridad, es la resolución de conflictos de nombres, en el caso de que su aplicación alguna vez se despliegue junto con otra aplicación que use los mismos nombres en la base de datos.

Si empaqueta y vende su producto, le recomiendo encarecidamente que utilice esquemas, por el bien de sus clientes. Si se desarrolla para una compra en particular, entonces no es una gran preocupación.

Answer 6

Sí se puede ignorar - en su mayor parte - si nunca jamás crear nada fuera de la (por defecto) esquema "dbo" .Un lugar que no se puede ignorar que es cuando se llama a una función almacenada - que siempre tiene que tener la notación "en dos partes":

select * from dbo.myFunc 

Sin embargo, se considera una buena práctica de utilizar siempre el "dbo. " prefijo (u otros prefijos de esquema, si su base de datos tiene varios esquemas).

Marc