Los usuarios que solicitan base de datos sin normalizar

Question

Yo estoy en las primeras etapas del desarrollo de una base de datos impulsada por el sistema y la mayor parte de el sistema gira en torno a un tipo de herencia de la relación.Hay un padre de la entidad, con cerca de 10 columnas y habrá cerca de 10 niños entidades que heredan de los padres.Cada niño entidad tendrá alrededor de 10 columnas.Pensé que tenía sentido para dar a los padres de la entidad de su propia tabla y darle a cada uno de los niños con sus propias tablas de una tabla por subclase de la estructura.

Hoy, a mis usuarios pidió ver la estructura del sistema que he creado.Se resistió a la idea de la tabla por subclase de la estructura.Se prefiere una gran ~100 columna de la tabla porque sería más fácil para ellos para realizar sus propias consultas personalizadas.

Debo considerar la posibilidad de eliminar la normalización de la base de datos para el bien de los usuarios?

Answer 1

Por supuesto que no. Siempre se puede crear una vista posterior para mostrarles lo que quieren ver.

Answer 2

Están pidiendo un informe.

Usted podría les dan acceso a una vista contiene todos los campos que requieren...de esa manera usted no estropear su modelo de datos.

Answer 3

No. Estructurar los datos correctamente y si los usuarios necesitan la vista de los datos sin normalizar crearlo como una vista en la base de datos.

Como alternativa, considere que tal vez un RDBMS no es la herramienta de almacenamiento adecuado para este proyecto.

Answer 4

Son los usuarios y no los programadores del sistema por una razón. Proporcionar una interfaz independiente para sus consultas. Los usuarios avanzados de este tipo pueden ser útiles tanto y un dolor de tratar. Simplemente explica que necesita la base de datos diseñada de una manera determinada para que pueda hacer su trabajo, y punto. Una vez que se haya cumplido y proporcionan otros medios para hacer más fácil la consulta.

Answer 5

¿Qué saben !? Se podría argumentar que usuarios no debe ser incluso tener acceso directo a una base de datos en el primer lugar.

Hacer eso te deja abierto a cuestiones de rendimiento masivo, sólo porque un par de usuarios ejecutan consultas ridículos.

Answer 6

¿Qué tal si ha creado una vista en el formato de sus usuarios querían mientras que todavía mantiene una tabla normalizada correctamente?

Answer 7

Además de una gran cantidad de las razones técnicas o en contra de la proposición de los usuarios, es necesario estar en misma página en la comunicación de las consecuencias de varios scenarious y (lo más importante) los costes de esas consecuencias . Si los usuarios son sus clientes y que están pagando que usted pueda hacer un trabajo, explicar que su horrible "propuestas" ideas puede costarles más dinero en el tiempo de desarrollo, los recursos de hardware adicionales, etc.

Esperamos que usted puede explicarlo de una manera que demuestra su experiencia y por qué su idea es un valor mucho mejor a sus usuarios en el largo plazo.

Answer 8

Como todo el mundo más o menos se ha mencionado, de esa manera a la locura, y siempre se puede construir una visión.

Si usted no puede conseguir que vengan en torno a este punto, los consideran mostrando este hilo y el número de profesionales que pesaba al decir que los usuarios están entrometiendo con las cosas que no se entienden completamente, y el impacto será una base socavada.

Una gran parte de las embarcaciones de los desarrolladores es la sensación de lo que no va a funcionar a cabo a largo plazo, y las reglas de normalización son casi canónica al respecto. Hay situaciones en las que necesita desnormalizar (almacenes de datos, etc.) pero esto no suena como uno de ellos!

También suena como si usted puede tener una marca particularmente preocupante del usuario en su mano - el desarrollador amateur que piensa que podrían hacer su trabajo mejor a sí mismos si tuvieran el tiempo. Esto puede o no puede ayudar, pero me he dado cuenta que esos tipos responden bien a la presentación - unas cuantas veces, he descubierto que si me visto aguda y mostrar un poco de la fuerza en mi personalidad, que también les hace sentir soy un experto y evita un montón de problemas antes de que comiencen.

Answer 9

No te recomiendo dar con una respuesta que no implique a alguien corriendo informes directos contra su base de datos. En el momento en que sucede, su estructura de base de datos está escrito en piedra y, básicamente, se puede considerar que el legado.

Una vista es un buen comienzo, pero más adelante, probablemente querrá estructurar esto como una exportación, para desacoplar más. Por supuesto, entonces te vas a encontrar a alguien que quiera de datos en "tiempo real". análisis de negocio adecuado por lo general revela que esto es innecesario. Los requisitos reales en tiempo real no se manejan mejor a través de sistemas de información.

Para que quede claro: yo personalmente estaría a favor de la tabla por subclase enfoque, pero no creo que en realidad es un problema tan grande como el de información directa de las mesas de transacción va a ser

.

Answer 10

optaría por una visión (como han sugerido otros) o una función con valores de tabla en línea (los beneficios de esto es que usted requiere parámetros - como un rango de fechas o una cuenta de cliente - que puede ayudar a evitar que los usuarios realizar consultas sin límites en el espacio del problema) en primer lugar. Un TVF en línea es realmente una vista parametrizada y es mucho más cerca de un punto de vista en cuanto a la forma en que el motor de los trata de lo que es una tabla de función con valores de instrucción múltiple o una función escalar, que puede realizar muy mal.

Sin embargo, en algunos casos, esto puede afectar al rendimiento de producción si la vista es compleja o intensivo. Con las consultas del usuario mal escrito ad hoc, sino que también puede causar bloqueos persisten a largo o se intensificaron aún más de lo que lo haría en una consulta mejor construido. También es posible que los usuarios malinterpretar un modelo de datos E-R y producen números multiplicados en los casos en los que hay muchos-a-uno o de muchos a muchas relaciones. La siguiente opción podría ser la de materializar estos puntos de vista con los índices o hacer tablas y mantenerlos actualizados, lo que nos lleva más cerca de mi siguiente opción ...

Por lo tanto, teniendo en cuenta los inconvenientes de la opción de vista y ya estamos pensando en la mitigación por empezar a hacer copias de los datos, la siguiente opción que yo consideraría es tener una versión separada de sólo lectura (para estos usuarios) de los datos que está estructurado de manera diferente. Por lo general, me gustaría ver primero un esquema de estrella de estilo Kimball. Usted no necesita tener un almacén de pleno derecho de datos en tiempo constante. Por supuesto, eso es una opción, pero usted podría simplemente mantener un modelo de reporte al día de los datos. Estrella esquemas son una forma especial de desnormalización y son particularmente buenos para la información numérica, y una estrella dada no deberían poder ser objeto de abuso por los usuarios de forma accidental. Puede mantener la estrella hasta la fecha en un número de maneras, incluyendo disparadores, los trabajos programados, etc. Pueden ser muy rápido para informar de las necesidades y se ejecutan en la misma instalación de producción - tal vez en una instancia independiente si no sólo una base de datos separada.

A pesar de que esta solución puede requerir que efectivamente más del doble de los requisitos de almacenamiento, en comparación con otras prácticas que podría ser una muy buena opción si usted entiende sus datos bien y no te importa tener dos modelos - uno para las transacciones y uno para el análisis (tenga en cuenta que ya se empezará a tener esta separación lógica de todos modos con el uso de una primera opción la más sencilla de vista).

Algunos arquitectos a menudo duplicar sus servidores y utilizar el modelo SAME con algún tipo de replicación con el fin de proporcionar un servidor de informes que se indexa más, o de otra manera. Dicho segundo servidor no afecta las operaciones de producción con los requisitos de información y puede mantenerse al día con bastante facilidad. Sólo habrá un modelo, pero por supuesto, esto tiene los mismos problemas de usabilidad con permitiendo a los usuarios el acceso ad hoc que sólo el modelo subyacente, sin la actuación afecta, ya que obtienen su propia zona de juegos.

Hay muchas maneras de pelar estos gatos. Buena suerte.

Answer 11

El cliente siempre tiene la razón. Sin embargo, es probable que dar marcha atrás al convertir sus necesidades en dólares y centavos el cliente. Una tabla 100 de columna requerirá dev tiempo adicional para escribir el código que hace lo que la base de datos haría automáticamente con la aplicación adecuada. Además, sus costes de apoyo serán más altos desde más código significa más problemas y menor facilidad de depuración.

Answer 12

Voy a hacer de abogado del diablo aquí y decir que ambas soluciones suenan como aproximaciones pobres de los datos reales. Hay una razón por la que los lenguajes de programación orientados a objetos no tienden a ser implementado con cualquiera de estos modelos de datos, y no se debe a las ideas de Codd 1970 sobre las relaciones fueron el sistema ideal para el almacenamiento y consulta de las estructuras de datos orientadas a objetos. : -)

Recuerde que SQL fue diseñado originalmente como un idioma de la interfaz de usuario (por eso se parece vagamente Inglés y en absoluto al igual que otras lenguas de la época: Algol, C, APL, prólogo). Las únicas razones que he escuchado para no exponer a una base de datos SQL para los usuarios de hoy en día son la seguridad (que podría acabar con el servidor!) Y la usabilidad (que quiere escribir SQL cuando se puede CLICKY luxación?), Pero si es su servidor y se querer, ¿por qué no dejar que ellos?

Teniendo en cuenta que "la mayor parte del sistema gira en torno a un tipo de herencia de la relación", a continuación, me gustaría considerar seriamente una base de datos que me permite que represento forma nativa, ya sea Postgres (si SQL es importante) o una base de datos de objetos nativos (que son impresionantes para trabajar, si no lo hace necesita la compatibilidad de SQL).

Por último, recuerda que todas las decisiones de ingeniería es una solución de compromiso. Por "pegarse a sus armas" (como otra persona propuesta), que está diciendo implícitamente el valor de los deseos de los usuarios son cero. No le pida SO para una respuesta correcta a esto, porque no sabemos lo que los usuarios quieren hacer con sus datos (o incluso lo que sus datos están, o que sus usuarios son). Ve a decirle por qué desea una solución de muchos cuadros, y luego llegar a una solución con ellos eso es aceptable para ambos.

Answer 13

tabla de clase de herencia y que están pidiendo individual herencia de tabla . Ambos diseños son válidos en determinadas situaciones.

Es posible que desee obtener una copia de los patrones de Martin Fowler de Enterprise Application Architecture para leer más sobre las ventajas y desventajas de cada diseño. Ese libro es un clásico de referencia a tener en su estantería, en cualquier caso.