¿Uso excesivo / uso correcto de esquemas?

Después de hacer esta pregunta en Stackoverflow , me pregunté dónde lo que he hecho es la mejor práctica correcta.

Básicamente, cada objeto que creo entra en un esquema con el nombre del esquema que refleja un uso. Por ejemplo, tengo los esquemas Audity Admin(entre otros).

Esto a su vez no deja objetos adentro dbo. ¿Esta bien? ¿Hay algo más que deba hacer?

Los esquemas no solo son una gran herramienta de seguridad (que es razón suficiente para usarlos), sino que también son perfectos para la separación lógica. Y parece que esto es lo que estás practicando.

Incluso si el requisito actual no necesita una seguridad especial, digamos que en el futuro todos los objetos de la base de datos relacionados con la Auditoría deben estar seguros para un rol de base de datos. Si estos objetos estuvieran dispersos por todo el dboesquema, entonces tendría que tener denypermisos explícitos en los objetos individuales. Pero con el Auditesquema, haces un sencillo denyy estás listo.

Yo personalmente practico el uso de esquemas. Sin embargo, como todas las cosas en las bases de datos, hay un medio feliz. No crearía un esquema para cada aspecto granular de la capa de datos. Hay demasiados esquemas y separaciones. Pero supongo que no estás cerca de eso.

Un patrón típico son los esquemas basados ​​en permisos, por lo que tendría WebGUI, Desktopetc. para el código, de modo que todos los objetos tengan los mismos permisos del esquema .

Si tiene grupos de usuarios claros, puede permitir eso, pero terminará con permisos superpuestos y desordenados en algún momento. Tiendo a diferir las comprobaciones de usuario / grupo a algunas comprobaciones dentro del código y no a los objetos de permisos: digamos que tiene usuarios Admin y HR Excel: todos estos ejecutan Desktopcódigo.

Los datos generalmente se comparten, por lo que tendría un Dataesquema, tal vez un Historyo Archiveesquema.

Algunos códigos no son públicos (como un UDF o un proceso interno), por lo que usaría un Helperesquema para el código que el código del cliente no debería ejecutar.

Finalmente, esquemas como Stagingo Systemo Maintenanceson útiles a veces.

Aunque no hay objetos de usuario en el dboesquema, el usuario dboposee todos los esquemas.

Ningún objeto en el dboesquema está perfectamente bien. Por lo que puedo ver, tampoco es un uso excesivo de esquemas, aunque cuántos esquemas son 'demasiados' es una pregunta bastante subjetiva (es comparable a "¿Cuántas clases debería tener mi diseño OO?").

La única otra cosa que mencionaría sería otorgar permisos en el esquema en lugar de objetos individuales (su pregunta SO no especifica nada sobre los permisos).

Me gustaría usar esquemas para separar la base de datos de acuerdo con los módulos y los patrones de uso. Creo que es muy fácil entender las tablas de la base de datos, por lo tanto, el mantenimiento se vuelve más fácil. Tenía los siguientes tipos de esquema en mi último proyecto de servidor sql. LT - Tablas de búsqueda

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

Para módulos grandes, también los separamos en más esquemas. Por ejemplo, el módulo de personal consta de más de 5 módulos.

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

También incluimos esquemas como para otras actividades TEMP, MANTENIMIENTO. En el estudio de gestión, puede filtrar utilizando el nombre del esquema. Un desarrollador responsable del MÓDULO1, filtra por nombre y trabaja casi todo el tiempo solo con estas tablas. Esto hace que sea muy fácil para los desarrolladores, dbas y principiantes entender las tablas de bases de datos.

Las mejores prácticas pueden ser diferentes para el servidor SQL que para Oracle, sin embargo, mi experiencia es que cuantos menos esquemas, mejor.
Me gusta tener un esquema para el programador / dba que tenga privilegios especiales y algún código para realizar tareas de mantenimiento. Todos los datos comerciales deben ir en un esquema para que sepa dónde están. Las convenciones de nomenclatura son suficientes para diferenciar entre el uso de la tabla o el código almacenado.
Puedo ver un caso en el que tiene varias unidades de negocio que deben diferentes datos con poca superposición, cada uno con su propio esquema. De lo contrario, que sea sencillo.