¿Las vistas de unión modificables son una opción de diseño razonable?

Question

Para ser claros, por modificable join view Me refiero a una vista construida a partir de la unión de dos o más tablas que permite insertar/actualizar/eliminar acciones que modifican cualquiera/todas las tablas de componentes.

Esto puede ser una pregunta específica de postgres, no estoy seguro. También me interesa si otros DBMS tienen características idiosincrásicas para vistas de unión modificables, ya que, por lo que puedo ver, no son posibles en SQL estándar.

Estoy trabajando en un esquema de Postgres, y algunas de mis lecturas recientes han sugerido que es posible construir vistas de unión modificables usando en su lugar reglas (CREATE RULE ... DO INSTEAD ...). Las vistas de unión modificables parecen deseables, ya que permitirían esconder una fuerte normalización detrás de una interfaz, proporcionando un mecanismo para la abstracción clásica. Las reglas son la única opción para la implementación, ya que actualmente es triggers cannot be set on views.

Sin embargo, la primera vista modificable que traté de diseñar se encontró con problemas, y descubrí que muchos consideran que las reglas no triviales son perjudiciales (ver enlaces en los comentarios al this SO answer). Además, no puedo encontrar ningún ejemplo de vistas de unión modificables en la web.

Preguntas (Editar para poner puntos más finos de las preguntas):

• ¿Tiene alguna experiencia con modificable vistas unidas y pueden proporcionarle un ejemplo concreto con seleccionar/insertar/borrar capacidad/actualización?
• ¿Son prácticas, es decir, se pueden tratar de forma transparente sin tener que caminar de puntillas alrededor de minas/agujeros negros?
• ¿Alguna vez son una buena opción de diseño, en términos de relación de funcionalidad/esfuerzo y facilidad de mantenimiento?

Agradecería mucho los enlaces a cualquier ejemplos/discusiones sobre este tema. Gracias.

Answer 1

Mi preferencia personal es usar vistas solo para leer datos, (virtualmente) nunca para insertar o actualizar. Al volver a normalizar los datos (que suenan como lo que está haciendo) en su base de datos, probablemente esté creando un sistema que será muy difícil de probar y mantener a largo plazo.

Si es posible, mirar a la cartografía de los datos no normalizados volver a un esquema normal de alguna parte de su código de aplicación, y proporcionando a la base de datos de esa manera (a tablas individuales en mi humilde opinión) en una sola transacción.

Answer 2

Los uso como reemplazo de los ORM. Creo que siempre y cuando no corras por todas partes a través de la base de datos, pueden ser fáciles de entender. Defino un esquema para una aplicación y luego las vistas que están en ese esquema son los métodos y operaciones de esa aplicación. El código del cliente puede ser en su mayoría automatizado después de eso ya que las vistas dan la abstracción que necesito para escribir el código genérico del cliente.

Las personas señalan que la reescritura de reglas no es una tabla real (pero se presenta como una) lo que hace posible escribir cosas que se romperán. Esto es posible, pero aún no lo he encontrado. La idea es ocultar la complejidad en la reescritura y luego solo hacer eliminaciones simples y actualizar con sin uniones. Si resulta que se necesita una unión, es hora de reescribir la regla, no la consulta de nivel superior.

Al final, me parece una forma muy compacta de escribir la base de datos.Todas las formas de interactuar con ella están escritas como reglas. Ninguna conexión debería tener acceso a una mesa real. Su lógica de negocio es muy explícita. Si una vista no tiene una regla UPDATE para ella, no se puede actualizar el período. Como ha escrito todo esto en el nivel de la base de datos en lugar del nivel del cliente, no está vinculado a un marco web o un idioma en particular. Esto lleva a mucha flexibilidad en la forma en que desea conectarse a la base de datos. Imagine que utilizó el marco web, pero a medida que pasa el tiempo necesita acceso directo a la base de datos para otra fuente. El acceso directo también omitirá todas las reglas comerciales de ORM con las que trabajó tan duro. Con una interfaz de escritura de reglas, puede exponer la interfaz sin temor a que la nueva conexión corrompa los datos.

Si la gente dice que realmente puede F UP una base de datos con ellos, entonces seguro que puede hacerlo. Pero puedes con todo lo demás también. Si la gente dice que no puedes usarlos en absoluto sin complicar las cosas, entonces no estoy de acuerdo.

Answer 3

Sé que en SQL Server si actualiza una vista debe limitar el cambio a una sola tabla de todos modos lo que hace que usar vistas para actualizar sea inútil en mi mente ya que tiene que saber qué campos van con qué tablas de todos modos.

Si desea abstraer la información y no tener que preocuparse por la estructura de la base de datos para las inserciones y las actualizaciones, una ORM puede hacer un mejor trabajo para usted que las vistas.

Answer 4

Dos enlaces rápidos:

1. Why using rules is bad idea
2. Triggers on views

Answer 5

Sí, tengo algo de experiencia con vistas actualizables en general. Creo que son prácticos en PostgreSQL. Al igual que todas las opciones de diseño, pueden ser una buena opción y pueden ser una mala elección.

Los considero particularmente útiles al tratar con tablas de supertipo/subtipo. Creo una vista para cada subtipo; la vista une el subtipo al supertipo. Revoca los permisos en las tablas base, escribe reglas para la vista y da acceso al código del cliente solo a las vistas. Toda la manipulación de datos hecha por el código del cliente pasa a través de la vista y las reglas definidas en ellos.

No creo que las reglas sean realmente diferentes de cualquier otra característica en cualquier otro entorno. Y por entorno, me refiero a C, C++, Java, Ruby, Python, Erlang y BASIC, no solo entornos dbms.

Utilice las buenas características de un idioma. Evita los malos

"No utilizar malloc()" es un mal consejo. "Siempre verifique el valor de retorno de malloc()" es un buen consejo. "Nunca uses reglas" es un mal consejo. "Evita usar reglas de maneras que se sabe que tienen un comportamiento cuestionable" es un buen consejo. Las reglas que necesita para ver las tablas de supertipo/subtipo son simples y fáciles de entender. No se portan mal.

En el nivel teórico, las vistas proporcionan independencia de datos lógicos. Pero eso solo es posible si las vistas son actualizables. (Y muchas vistas deben ser actualizadas directamente por el motor de base de datos, sin necesidad de reglas o factores desencadenantes.)

Answer 6

nunca he utilizado vistas modificables de cualquier tipo, pero a medida que se preguntan si son una "opción de diseño razonable", puedo sugerir una opción de diseño alternativo con muchos beneficios en los que no se necesitan puntos de vista modificables: un Transactional API

Básicamente lo que esto significa es:

• los usuarios no tienen acceso a las tablas y no pueden emitir insert, update, delete declaraciones en todos los
• los usuarios tienen acceso a las funciones que represen t transacciones bien definidas: en el nivel más simple, estas pueden simplemente hacer un solo LMD, pero a menudo no lo harían. Lo importante es que se asignan a las transacciones en el sentido de 'negocio' y no en el sentido de 'base de datos'
• para realizar consultas, los usuarios tienen acceso a (no modificable) Vistas
vistas

Answer 7

Yo suelo hacer en la forma de "último-registro válido" simplemente ocultando y rastreando modificaciones (como un wiki)
El único inconveniente que veo es: luego usa su vista como una tabla, y la une con cualquier cosa, y y lo usa en "wheres", e inserta registros en él, y más, pero detrás ha perdido mucho rendimiento en comparación con las mismas acciones en comparación con una tabla real (más grande y más compleja). Creo que depende de cuántas personas deben entender el esquema. Es cierto que algunos DBMS también admiten indexar las vistas, pero creo que se pierde una cantidad importante de rendimiento de todos modos. Perdón por mi inglés.