Esquemas de PostgreSQL-Escenario/Caso de Uso
Me disculpo por mi pregunta como novato, pero soy un novato en PostgreSQL y esquemas. Me cuesta entender el propósito de los esquemas en PostgreSQL.. y en general. ¿Cuáles son los posibles casos de uso de los esquemas?
El libro que tengo indica que los esquemas son como directorios que no se pueden anidar. OK, así que lo tomo esquemas son un medio para agrupar tablas en una base de datos. El libro no aborda cómo se implementa esto, ni menciona los usos potenciales, excepto por un trivial ejemplo (párrafo siguiente).
Un beneficio y un caso de uso potencial #1
Hasta ahora solo he entendido un beneficio (aparentemente trivial) para los esquemas. Esta ventaja es que puede tener varias tablas con el mismo nombre y siempre y cuando cada tabla esté en un esquema diferente, no habrá conflicto porque el calificador de espacio de nombres (el nombre del esquema) se puede usar para abordar la tabla en particular deseada.
Realmente no entiendo por qué tienes múltiples tablas del mismo nombre para empezar. Creo que este es un caso extremadamente raro, sin embargo, los documentos vienen a mí como si los esquemas deben ser utilizados por todo el mundo. Tener varias tablas del mismo nombre me parece una mala gestión de proyectos y permitir tales malas prácticas no parece tener valor. Al final, solo estás permitiendo que se haga un desastre.
El único escenario que se me ocurre en el que podría haber conflictos de nombres de tablas que deberían permitirse es cuando se tiene una clase que está aprendiendo SQL y el administrador de TI de la escuela quiere que cada estudiante pueda crear tablas de su agrado. Por supuesto, la pregunta en mi mente es ¿por qué el administrador no crea 1 db por estudiante en lugar de 1 db para todos y 1 esquema para cada estudiante? P1: ¿Por qué?
¿Cuáles son otros casos de uso que muestran el beneficio de los esquemas?
EJECUCIÓ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 el usuario como tal:
usuario1='admin' -- tableA, tableU, tableJ, tableK,
usuario2='joe' ------ tableU, tableJ,
usuario3='kate ----- tableU, tableK.
En el ejemplo anterior, mi intención es que tableU se comparta entre los usuarios (a través del esquema joe y el esquema kate). No deben obtener su propia copia independiente de la tabla, deben compartir el acceso común a esta tabla. Este tipo de el uso tiene sentido para mí. Los usuarios deben agregar/modificar / potencialmente eliminar registros... no añadir/modificar / eliminar tablas. Sin embargo, no estoy seguro de que esto sea posible con esquemas PostgreSQL. P2: Si quisiera compartir tableU como he descrito anteriormente, ¿schema joe y schema kate obtendrían cada uno su propia copia de la tabla o puedo especificar que no deberían obtener su propia copia y en su lugar compartir el acceso a una tabla existente?
TableJ es mismo como tableK ... excepto que Kate no puede usar tableJ y Joe no puede usar tableK. Esta parece ser la esencia de los esquemas para mí de acuerdo con mi comprensión limitada de los esquemas. P3: ¿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 un desperdicio 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 tabla. Estaríamos tirando conceptos clave como la normalización por la ventana. Sería un desastre inalcanzable. En mi mente, cada usuario debería agregar / modificar / eliminar registros a una tabla común en una base de datos común.
He visto a personas en mis búsquedas de Google sobre esquemas hacer un esquema+tablas separadas para cada cliente en línea a su sitio web. Tienen como 100,000 esquemas. P4: ¿Qué me estoy perdiendo aquí? Esto parece extremo por decir lo menos. Deberían estar agregando registro(s) a tabla estándar(s) para cada cliente, no a hacer esquemas y tablas para cada cliente. Esto solo aumenta mi confusión.
De todos modos, espero haber declarado los puntos clave de mi confusión con suficiente claridad.
Lo que estoy buscando es:
(1) Para aclarar las ventajas de los esquemas a través de ejemplos de casos de uso realistas.
(2) Aclarar los detalles de implementación de los esquemas.
EDITAR v. 3
Caso de uso potencial #2
Si entendiera Neville K correctamente, sugiere como un caso de uso:
1 DB que tiene 3 esquemas. 1 esquema por usuario como tal (username = = schema_name en ex.):
user1= 'admin' tabl 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 gerente de proyecto. La aplicación que utiliza Joe está restringida a Tablas relacionadas con finanzas, la aplicación que usa Kate está restringida a 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 (se aplica a nivel de base de datos).
P5: ¿No estaría la misma restricción sin esquemas? Qué tablas están disponibles para qué aplicación es una función de qué tablas se establecieron para ser utilizadas por la aplicación en el momento en que la aplicación fue hecha por el equipo de desarrollo. ¿No? O somos suponiendo que estamos utilizando aplicaciones listas para usar que apunta a una base de datos y nos preocupa que la aplicación no pueda en su configuración restringirse a ciertas tablas (y esta restricción bloqueada con una contraseña dentro de la aplicación lista para usar)?
Caso de uso potencial #3
Si entendí Catcall correctamente, sugirió como 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 para múltiples clientes que necesitan servicio de base de datos. Como tal, surge un escenario como multi-tenant. En este punto usted puede elegir tener:
(1) Una base de datos separada para cada inquilino (cliente)
- Más seguro y conveniente, pero puede soportar menos inquilinos por sistema.
(2) Una base de datos compartida con un esquema para cada inquilino (cliente)
- Menos seguro y un poco menos conveniente, pero puede soportar más inquilinos por sistema.
Caso de uso potencial #4
Si entendiera Scott Marlowe y Catcall correctamente, 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.
4 answers
He visto gente en mis búsquedas de Google acerca de los esquemas esquema + tablas para cada cliente en línea a su sitio web. Tienen como 100,000 esquemas. P3: ¿Qué me estoy perdiendo aquí? Esto parece extremo para decir la menos. Deberían estar agregando registro(s)) a tabla (s) estándar para cada cliente no hacer esquemas y tablas para cada uno cliente.
Una base de datos por inquilino (cliente) es fácil de construir, y le da el aislamiento más fuerte entre inquilinos, y la recuperación ante 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. Un dbms puede admitir más inquilinos por servidor con un esquema por inquilino que con una base de datos por inquilino. La recuperación ante 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 tenant. Hardware y copia de seguridad son más baratos; desastre la recuperación de un inquilino puede ser una verdadera perra. (Para recuperar datos de un solo inquilino, debe recuperar algunas filas en cada tabla. El rendimiento sufre para todos los inquilinos cuando eso sucede.) El aislamiento es más complicado. Dado que 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 "multi-tenant database design". Así también tiene una etiqueta multi-tenant.
Otro el 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 las características de " cuentas por pagar "podrían ir en el esquema" ap". También uso esquemas para extensiones de PostgreSQL. En mi bd, instalé la extensión hstore en el esquema "hst", la extensión tablefunc en el esquema" tbf", etc.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-02-23 23:14:39
La respuesta de Neville K captura la esencia, pero quizás es un poco breve.
Los esquemas son esencialmente espacios de nombres. Son útiles en el mismo tipo de situaciones que los espacios de nombres son útiles en la programación: donde tienes muchas cosas, tantas que quieres particionarlas en sub-colecciones separadas (muchas many pero menos de (digamos) 10.000 sub-colecciones, dado que hay un solo nivel), mientras que ser capaz de interactuar entre ellas. El uso de esquemas puede permitir más nombres "naturales" estándares para otros objetos de base de datos.
Como un aparte, 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. Es 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.) que uno llega a entender que los beneficios de los espacios de nombres superan sus costos.
En un a una edad más temprana (y no con PostgreSQL), trabajé para una oficina de computadoras con aproximadamente 20 clientes, que van desde 250 usuarios concurrentes del DBMS hasta uno, cada uno a través de líneas telefónicas privadas arrendadas. (Esto fue antes de Internet.) Cada cliente tenía su propio esquema, con un usuario administrador (rol) que podía crear y eliminar a otros usuarios a medida que los empleados iban y venían, otorgar y revocar privilegios, y hacer una cantidad limitada de trabajo de definición de datos e importación/exportación en su propio esquema. Como desarrollador tuve que usar porque solo había una instancia de DBMS y una base de datos. Tan... si lo anterior no es convincente, se 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 en día, una situación algo similar a la mía podría surgir en un entorno de laboratorio, donde varios investigadores (o cientos de estudiantes) cada uno quiere trabajar en sus propios datos mientras tiene acceso a un conjunto común en el esquema público. El uso de esquemas ayuda a detener accidentes: pisoteando inadvertidamente los datos de los demás.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-11-03 06:27:05
Aquí hay otro uso común que he visto. Los esquemas y search_path permiten a dos o más desarrolladores trabajar en la misma copia única de una base de datos grande sin necesidad de sus propias copias, pero sin interponerse entre sí.
Digamos que Joe está trabajando en la tabla de comentarios, y Jim está trabajando en la tabla de flujo de trabajo. Ambos necesitan las tablas de usuarios, grupos, etc. Joe crea un esquema, crea su propia versión de trabajo de la tabla de comentarios, y puede revolcarse con él en will:
create schema joe;
create table joe.comments (rest of new tabledef here);
set search_path='joe','public';
Ahora cuando Joe hace alter table en la tabla joe.comments, Jim no ve cambios y su desarrollo no se ve afectado por una tabla joe.comments rota, etc. Cuando el código de Joe, que tiene un search_path de 'joe','public' se ejecuta, ve las tablas de comentarios de joe mientras que todos los demás ven el original.
Después de pruebas exhaustivas, la tabla de comentarios de Joe se puede colocar básicamente en lugar del original de un solo golpe sin interrupción en el desarrollo de Jim. Multiplicar esta vez 40 desarrolladores y permite que todos los 40 a trabajar en la misma base de datos de desarrollo sin explotar las cosas de los demás (o al menos con menos frecuencia).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-09-11 20:10:41
El principal beneficio de los esquemas es proporcionar una agrupación lógica para las tablas de la base de datos. Los casos de uso más probables son:
- Para ejecutar diferentes aplicaciones lógicas dentro de la misma base de datos - por ejemplo, es posible que tenga un sistema enterprise, y desea crear esquemas llamados "userprofiles", "proyectos", "finanzas" sucesivamente.
- Para crear versiones similares del mismo grupo de tablas, por ejemplo para "desarrollo", "qa" y "producción"
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-04-15 15:42:35