database - pgmodeler - postgresql modeler free
Esquemas PostgreSQL-Escenario de uso/Caso (4)
Me disculpo por mi pregunta de novato, pero soy un novato en PostgreSQl y en los esquemas. Me cuesta entender el propósito de los esquemas en PostgreSQL ... y en general. ¿Cuáles son los posibles casos de uso para los esquemas?
El libro que tengo indica que los esquemas son como directorios que no se pueden anidar. OK, entonces considero que los esquemas son un medio para agrupar tablas en un db. El libro no aborda cómo se implementa esto, ni menciona los usos potenciales a excepción de un ejemplo trivial (siguiente párrafo).
Un caso de uso de beneficios y potencial n. ° 1
Hasta ahora solo he entendido un beneficio (aparentemente trivial) para los esquemas. Este beneficio es que puede tener varias tablas con el mismo nombre y siempre que cada tabla esté en un esquema diferente, no habrá conflicto porque el calificador del espacio de nombres (el nombre del esquema) se puede usar para abordar la tabla particular deseada.
Realmente no entiendo por qué tendrían varias tablas del mismo nombre para empezar. Creo que este es un caso extremadamente raro, sin embargo, los documentos se me presentan como si los esquemas debieran ser utilizados por todos. Tener varias tablas con el mismo nombre me parece una gestión de proyectos deficiente y permitir esa mala práctica no parece ser un valor. Al final, solo permites que se haga un desastre.
El único escenario en el que puedo pensar donde podría tener conflictos de nombre de tablas que deberían permitirse es cuando tienes una clase que está aprendiendo SQL y el administrador de TI de la escuela quiere que cada alumno pueda crear tablas de su agrado. Por supuesto, la pregunta que tengo en mente es por qué el administrador no solo crea 1 db por alumno en lugar de 1 db para todos y 1 esquema para cada alumno. Q1: ¿Por qué?
¿Cuáles son algunos otros casos de uso que muestran el beneficio de los esquemas?
APLICACIÓN O NATURALEZA DE
También estoy confundido acerca de la implementación / naturaleza de los esquemas.
Supongamos que tenemos 1 DB que tiene 3 esquemas. 1 esquema por usuario como tal:
user1 = ''admin'' - tableA, tableU, tableJ, tableK,
user2 = ''joe '' ------ tableU, tableJ,
user3 = ''kate ----- tableU, tableK.
En el ejemplo anterior, mi intención es que tableU se comparta entre los usuarios (a través del esquema joe & schema kate). No deberían obtener su propia copia independiente de la tabla, deben compartir el acceso común a esta tabla. Este tipo de uso tiene sentido para mí. Los usuarios deberían agregar / modificar / eliminar potencialmente registros ... no agregar / modificar / eliminar tablas. Sin embargo, no estoy seguro de que esto sea posible con los esquemas de PostgreSQL. P2: Si quisiera compartir tableU como describí anteriormente, ¿obtendrían schema joe y schema kate cada una de las copias de la tabla o puedo especificar que no deberían obtener su propia copia y compartir el acceso a una tabla existente?
tableJ es lo mismo que tableK ... excepto que Kate no puede usar tableJ y joe no puede usar tableK. Esta parece ser la esencia de los esquemas para mí según mi limitada comprensión de los esquemas. Q3: ¿Cuál es el propósito de hacer una copia de una tabla para cada usuario? Las 2 tablas tienen la misma estructura (columnas y restricciones) y es una pérdida de espacio de almacenamiento hacer una copia independiente de dicha tabla para cada usuario. También creo que sería una pesadilla si cada usuario tuviera su propia copia de cada mesa. Lanzaríamos conceptos clave como normalización por la ventana. Sería un desastre inmanejable. En mi opinión, cada usuario debería agregar / modificar / eliminar registros a una tabla común en un DB común.
He visto personas en mis búsquedas de Google sobre esquemas crear un esquema + tablas por separado para cada cliente en línea en su sitio web. Tienen como 100,000 esquemas. P4: ¿Qué me estoy perdiendo aquí? Esto parece extremo por decir lo menos. Deben agregar registro (s) a la (s) tabla (s) estándar (s) para cada cliente que no realice esquemas y tablas para cada cliente. Esto solo aumenta mi confusión.
De todos modos, espero haber indicado los puntos clave de mi confusión con la suficiente claridad.
Lo que estoy buscando es:
(1) Para aclarar los beneficios de los esquemas a través de ejemplos de casos de uso realistas.
(2) Para borrar los detalles de implementación de esquemas.
EDITAR v.3
Caso de uso potencial n. ° 2
Si entendí a Neville K correctamente, sugirió como un caso de uso:
1 DB que tiene 3 esquemas. 1 esquema por usuario como tal (username == schema_name en ej.):
user1 = ''admin'' - tableA, tableLogin, tblFin1, tblFin2, tblFin3, tblPrj1, tblPrj2, tblPrj3.
user2 = ''joe '' ------ tableLogin, tblFin1, tblFin2, tblFin3
user3 = ''kate ----- tableLogin, tblPrj1, tblPrj2, tblPrj3.
Aquí, Joe está en el departamento de Fin y Kate es la gerente de proyecto. La aplicación que usa joe está restringida a las tablas relacionadas con Finanzas, la aplicación que usa Kate está restringida a las tablas de administración de proyectos. Esta restricción se aplica a través de que su nombre de usuario está vinculado a un esquema que está vinculado a una ruta de búsqueda (aplicada a nivel de base de datos).
P5: ¿No existiría la misma restricción sin esquemas? Qué tablas están disponibles para qué aplicación es una función de las tablas que se establecieron para ser utilizadas por la aplicación en el momento en que el equipo de desarrollo realizó la aplicación. ¿No? O asumimos que estamos usando aplicaciones listas para usar que señala a un DB y nos preocupa que la aplicación no pueda restringirse en ciertas configuraciones a ciertas tablas (y esta restricción se bloquee con una contraseña dentro del estándar) solicitud)?
Caso de uso potencial n. ° 3
Si entendí Catcall correctamente, sugiere como un caso de uso:
Un escenario en el que desea alquilar / arrendar los servicios de un servidor de base de datos alojado en 1 sistema físico a múltiples clientes que necesitan un servicio de base de datos. Como tal, surge un escenario de varios inquilinos. En este punto, puede elegir tener:
(1) Una base de datos separada para cada inquilino (cliente)
-Más seguro y conveniente, pero puede admitir menos inquilinos por sistema.
(2) Una base de datos compartida con un esquema para cada inquilino (cliente)
-Menos seguridad y un poco menos conveniente, pero puede admitir más inquilinos por sistema.
Caso de uso potencial n. ° 4
Si entendí correctamente a Scott Marlowe y Catcall, otro caso de uso sería:
Usar esquemas para aislar el nuevo contenido de los desarrolladores durante el desarrollo. Más tarde puede combinar el trabajo con otro esquema.
He visto personas en mis búsquedas de Google sobre esquemas crear un esquema + tablas por separado para cada cliente en línea en su sitio web. Tienen como 100,000 esquemas. P3: ¿Qué me estoy perdiendo aquí? Esto parece extremo por decir lo menos. Deben agregar registro (s) a la (s) tabla (s) estándar (s) para cada cliente que no realice esquemas y tablas para cada cliente.
Una base de datos por inquilino (cliente) es fácil de construir, y le proporciona el mayor aislamiento entre los inquilinos y la recuperación de desastres más simple. Pero es relativamente caro.
Un esquema por inquilino también es fácil de construir. Hay un menor grado de aislamiento entre los inquilinos. A dbms puede admitir más inquilinos por servidor con un esquema por inquilino que con una base de datos por inquilino. La recuperación de desastres para un inquilino es más complicada que con una base de datos por inquilino.
Un esquema compartido requiere que cada fila tenga un identificador de inquilino. El hardware y la copia de seguridad son más baratos; la recuperación de desastres para un inquilino puede ser una verdadera perra. (Para recuperar datos para un único inquilino, debe recuperar algunas filas en cada tabla. El rendimiento se ve afectado por todos los inquilinos cuando eso sucede). El aislamiento es más complicado. Como los inquilinos comparten tablas, asegurarse de que ningún inquilino pueda acceder a los datos de otros inquilinos es mucho más difícil que con una base de datos o un esquema por inquilino.
El término de búsqueda para este material es "diseño de base de datos de múltiples usuarios". SO también tiene una etiqueta multi-tenant .
Otro uso común es agrupar objetos de base de datos que pertenecen juntos. Por ejemplo, si estuviera desarrollando una base de datos de contabilidad, todos los objetos que implementan características de "cuentas por pagar" podrían ir en el esquema "ap". También uso esquemas para extensiones de PostgreSQL. En mi db, instalé la extensión hstore en el esquema "hst", la extensión tablefunc en el esquema "tbf", etc.
Aquí hay otro uso común que he visto. Los esquemas y la search_path permiten que dos o más desarrolladores trabajen en la misma copia única de una gran base de datos sin necesitar sus propias copias, pero sin interponerse en el camino del otro.
Digamos que Joe está trabajando en la tabla de comentarios, y Jim está trabajando en la tabla de flujo de trabajo. Ambos necesitan tablas de usuarios, grupos, etc. Joe crea un esquema, crea su propia versión de trabajo de la tabla de comentarios, y puede ensuciarlo a voluntad:
create schema joe;
create table joe.comments (rest of new tabledef here);
set search_path=''joe'',''public'';
Ahora, cuando Joe alter table en la tabla joe.comments , Jim no ve ningún cambio y su desarrollo no se ve afectado por una tabla de joe.comments rota, etc. Cuando se joe.comments el código de Joe, con un search_path de ''joe'',''public'' , ve las tablas de comentarios de Joe mientras todos los demás ven el original.
Después de una evaluación exhaustiva, la tabla de comentarios de Joe se puede colocar básicamente en lugar del original de una sola vez sin interrupción en el desarrollo de Jim. Multiplicar esta vez a 40 desarrolladores y permite que los 40 trabajen en el mismo db de desarrollo sin explotar los elementos del otro (o al menos con menos frecuencia).
El beneficio clave para los esquemas es proporcionar una agrupación lógica para las tablas de su base de datos. Los casos de uso más probables son:
- Para ejecutar diferentes aplicaciones lógicas dentro del mismo DB, por ejemplo, puede tener un sistema empresarial y desea crear esquemas llamados "perfiles de usuario", "proyectos", "finanzas", etc.
- Para crear versiones similares del mismo grupo de tablas, por ejemplo para "desarrollo", "qa" y "producción"
La respuesta de Neville K captura la esencia, pero es quizás un poco breve.
Los esquemas son esencialmente espacios de nombres. Son útiles en el mismo tipo de situaciones en que los espacios de nombres son útiles para la programación: donde tiene muchas cosas, tantas que desea dividirlas en subcolecciones separadas (muchas, pero menos de (digamos) 10.000 subcategorías). colecciones, dado que hay un solo nivel), mientras se puede interactuar entre ellos. El uso de esquemas puede permitir estándares de nomenclatura más ''naturales'' para otros objetos de base de datos.
Por otro lado, el valor de los espacios de nombres tampoco es apreciado por los nuevos programadores. Ese beneficio aparentemente trivial de permitir que varios objetos tengan el mismo nombre no es tan trivial, resulta. Solo cuando uno ha trabajado durante un tiempo en proyectos más grandes (con miles de ''objetos de código'': tablas, vistas, índices, procedimientos almacenados, dominios, etc.) uno llega a comprender que los beneficios de los espacios de nombres superan sus costos.
En una época anterior (y no con PostgreSQL), trabajé para una oficina de informática con aproximadamente 20 clientes, que iban desde 250 usuarios concurrentes del DBMS hasta uno, cada uno a través de líneas telefónicas arrendadas privadas. (Esto fue antes de Internet.) Cada cliente tenía su propio esquema, con un usuario administrador (función) que podía crear y eliminar otros usuarios a medida que los empleados entraban y salían, otorgar y revocar privilegios y hacer una cantidad limitada de trabajo de definición de datos y importar / exportar en su propio esquema. Como desarrollador tuve que usar esquemas porque solo había una instancia de DBMS y una base de datos. Entonces ... si lo anterior no es convincente, podría decir que los esquemas están en el estándar SQL (por razones históricas), por lo tanto, PostgreSQL tiene soporte para esquemas.
Hoy, una situación similar a la mía podría surgir en un entorno de laboratorio, donde varios investigadores (o cientos de estudiantes) quieren trabajar en sus propios datos mientras tienen acceso a un conjunto común en el esquema público. El uso de esquemas ayuda a detener accidentes: pisotear inadvertidamente los datos de los demás.