¿Se debe evitar el esquema dbo?

Cuando se trata del esquema dbo:

• ¿Es una práctica recomendada evitar usar el esquema dbo al crear objetos de base de datos?
• ¿Por qué debería evitarse el esquema dbo o debería?
• ¿Qué usuario de la base de datos debería poseer el esquema dbo?

Puede ser una buena práctica porque cuando tiene otros usuarios usando la base de datos, desea limitar su acceso con esquemas. Por ejemplo, en una base de datos tiene las siguientes tablas.

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

Como director de recursos humanos, puedo acceder a cualquier cosa en el HResquema, como ITdirector puedo ver los nombres de usuario y los niveles de acceso de los empleados. El Engineeringdepartamento puede ver qué sitios de trabajo están activos, etc. Si dbo fuera el esquema establecido para todas las tablas, me resultaría más difícil segmentar mis datos y proporcionar roles de acceso.

La idea, creo, en SQL Server es ofrecer un producto al que puedan acceder y consultar diferentes departamentos. En realidad, solo los DBA / DBDevs realmente acceden a la base de datos y generalmente solo almacena datos de la aplicación.

También ayuda con la legibilidad y la capacidad de administración. A primera vista, puedo identificar fácilmente qué tabla contiene qué datos y cómo se separan los datos.

Personalmente prefiero definir esquemas como práctica general. Recuerde que el esquema es griego para el plan, tener una estructura de esquema establecida lo ayuda a planificar e identificar datos.

Creo que esto realmente se reduce a la preferencia del usuario ya que no hay una razón tecnológica real para hacerlo. De hecho, por simplicidad, digo que siempre use dbo a menos que sus requisitos de seguridad estipulen lo contrario. Por supuesto, siempre puede hacerlo solo con fines organizativos.

En todo caso, se debe evitar dbo porque es el valor predeterminado para SQL Server, tampoco es descriptivo en absoluto. Como todos los otros nombres predeterminados, dado que es conocido, hace que la vida de un hacker sea mucho más fácil (aunque si están en el punto en el que solo están tratando de descifrar el nombre de su esquema, probablemente ya estén molestos).

Donde trabajo, utilizamos esquemas para dividir la base de datos en secciones lógicas y asignar permisos a los esquemas.

Por ejemplo, podemos tener un sistema de inventario con una base de datos. Las tablas principales pueden estar en el esquema inv. Si importamos algo a la base de datos, se utilizará un esquema de etapas como parte del proceso de importación. Si tenemos algún procedimiento almacenado en el sistema al que los usuarios no necesitan acceder, lo colocamos en un esquema sp.

Anteriormente no era la mejor práctica porque los esquemas estaban ocultos antes de SQL 2005, todo se puso en el esquema dbo. El equipo de SQL Server lo muestra como una mejor práctica y publicó un artículo al respecto: Mejores prácticas de SQL Server - Implementación de esquemas de objetos de base de datos

En cuanto a su otra pregunta sobre quién debería ser el propietario: el esquema dbo es propiedad de la cuenta de usuario dbo.