¿Se debe evitar el esquema dbo?

29

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?
jrara
fuente
Algún consultor dijo que es una buena práctica evitar el esquema dbo y siempre crear esquemas definidos por el usuario y asignar objetos a estos esquemas.
jrara
He encontrado esta declaración también de Alexander Kuznetsov en los comentarios de este blog posterior :
jrara

Respuestas:

22

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.

Ryan
fuente
6

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.

Eric Humphrey - lotsahelp
fuente
1
100% detrás de este enfoque. A menudo dejo las tablas "núcleo" en el esquema dbo por simplicidad y empiezo a agregar cuando sea necesario. Normalmente, el primer esquema separado que agrego es "Stage" o "Staging", para agrupar mis tablas de etapas por separado. Otro ejemplo sería agregar datos de una fuente externa, por ejemplo, Twitter. En lugar de prefijar todas las tablas (es decir, TwitterAccount, TwitterStatus, etc.) crearé un esquema "Twitter".
robopim
5

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.

DForck42
fuente
1
+1 para "evitarlo porque es el valor predeterminado". Obliga a los usuarios a al menos pensar un poco al crear un objeto.
BradC