Es la creación de un “registro ficticio” a fuerza de los datos-base obedecen la lógica de negocio, una idea buena o una muda?

Question

En algunos proyectos que veo que es necesario un registro ficticio para crear en dB con el fin de mantener la marcha en la lógica de negocio sin romper las limitaciones dB.

Hasta ahora he visto su uso de 2 maneras:

• Mediante la adición de un campo como IsDummy
• Mediante la adición de un campo algo llamado ObjectType que apunta a un tipo: Maniquí

Ok, ayuda en lo que se debe lograr.

Pero lo que me hace sentir alerta sobre este tipo de soluciones es a veces hay que tener en cuenta que existen algunos registros ficticios en la aplicación que necesita ser manejado en algunos procesos. Si no es así, se enfrenta a algunos problemas hasta que se da cuenta de su existencia o hasta que alguien en el equipo te dice " ¡Eh, tú han olvidado los registros ficticios. También debe hacer ... "

Así que la pregunta es: ¿Es una buena idea para crear registros ficticios para mantener la lógica de negocio, ya que es sin hacer el Db se quejan? En caso afirmativo, ¿cuál es la mejor práctica para evitar que los desarrolladores saltarse su existencia? Si no es así, ¿qué hacer para evitar que usted se caiga en una situación en la que se termina con una única opción de crear un registro ficticio?

Gracias!

Answer 1

El uso de registros ficticios es inferior a conseguir las limitaciones de la derecha.

A menudo hay una tentación de utilizarlas porque el uso de registros ficticios puede parecer el camino más rápido para ofrecer una nueva característica (y tal vez a veces lo es), pero nunca son parte de un bien diseño, porque se esconden diferencias entre su lógica de dominio y modelo de datos.

Answer 2

registros ficticios sólo son necesarios cuando el modelador no puede cambiar fácilmente la definición de base de datos, lo que significa que la definición y / o el modelo de datos es bastante malo. Uno nunca debe terminar en una situación en la que tiene que haber un código especial en la capa de aplicación para manejar casos especiales en la base de datos. Esa es una pesadilla de mantenimiento garantizado.

Cualquier definición bueno o modelo permitirá cambios fácilmente, sin "afectar código existente".

Toda la lógica de negocio [que se define en la base de datos] debe implementarse mediante restricciones ANSI SQL, cheques y Reglas. (Por supuesto, las estructuras de nivel inferior ya están limitadas a través de Dominios / Tipos de datos, etc., pero yo no clasificarlos como "reglas de negocio".) Me aseguro que no me acaban de tener que aplicar maniquíes, simplemente por hacer eso.

Si eso no se puede hacer, a continuación, el modelador carece de conocimientos y experiencia. O requisitos de nivel superior, tales como la normalización, se han roto, y que presenta obstáculos para la implementación de restricciones que dependen de ellos; También significa que el modelista fallado.

nunca he necesaria para romper este tipo de restricciones, o añadir registros ficticia (y he trabajado en una gran cantidad de bases de datos). He quitado maniquí registros (y duplicados) cuando he vuelto a trabajar las bases de datos creadas por otros.

Answer 3

nunca he correr a través de tener que hacer esto. Si necesita hacer esto, hay algo mal con su estructura de datos, y va a causar problemas más abajo en la línea para reportar ...

Answer 4

Uso de los maniquíes es mudo.

En general, usted debe tratar de obtener su derecho de lógica sin ellos. Los he visto usan también, pero sólo como una solución de emergencia. Su descripción suena demasiado parecido a lo que es una práctica habitual. Eso causaría más problemas de los que resuelve.

Answer 5

La única razón que puedo ver por la adición de registros "ficticios" es cuando usted tiene un serio mal diseño y la aplicación de base de datos.

No es definitivamente una práctica común.

Si su lógica de negocio depende de un registro existente entonces usted necesita para hacer una de dos cosas: o bien asegurarse de que un archivo correcto se crea antes de ejecutar esa lógica; o bien, cambiar la lógica para tomar en cuenta la información faltante.

Answer 6

Creo que cualquier situación en la que hay algo que no es muy fácil de distinguir como "lógica de negocio" es un motivo de tratar de pensar en una mejor manera.

El hecho de que usted menciona "que apunta a un tipo: ficticio" me lleva a creer que está utilizando algún tipo de ORM para el manejo de sus datos de acceso. Un muy buen punto de control (aunque no la única) de soluciones ORM como NHibernate es que su código fuente describe de manera muy explícita sus estructuras de datos conducción de su aplicación. Esto no sólo permite el acceso de datos para ser fácilmente manejado bajo control de origen, sino que también permite una depuración más sencilla en la línea debe producirse un problema (y seamos sinceros, no es una cuestión de SI ocurrirá un problema, pero cuando).

Cuando se introduce una especie de "muleta" como un registro ficticio, que están ignorando el punto de una base de datos. Una base de datos está ahí para hacer cumplir las reglas en contra de sus datos, en un esfuerzo por eliminar la necesidad de este tipo de cosas. Le recomiendo que tome un vistazo a su lógica de la aplicación antes de recurrir a este tipo de técnica. Piense en su dev del compañero, o un nuevo alquiler. Lo que si tienen que añadir una característica y se olvide de su poca lógica "registro ficticio"?

Usted menciona a sí mismo en su aprehensión pregunta sentimiento. A su intuición. Deshacerse de los registros ficticios.

Answer 7

Tengo que ir con el sentimiento común aquí y argumentar en contra de registros ficticios.

Lo que sucederá es que un nuevo desarrollador no tendrá conocimiento de ellos y no código para manejarlos, o eliminar una tabla y se olvide de añadir un nuevo registro ficticio.

Los he experimentado en bases de datos heredadas y he visto tanto de la mencionada suceder.

También el ya existen, más difícil es para llevarlos a cabo y cuanto más código que tiene que escribir a tener en cuenta estos registros ficticios que podrían probablemente haber quitado si usted acaba de hacer el diseño original sin ellos.

Answer 8

La solución correcta sería la de actualizar su lógica de negocio.

Para citar su explicación más detallada:

Suponga que tiene un objeto de paquete y hay que implementar una lógica de negocio que un paquete sin ningún contenido no puede ser creado. Ustedes crearon algunas reglas de negocio y la capa diseñado su Db con las limitaciones pertinentes. Pero después de algunos años se solicita una nueva característica y para lograr eso hay que ser capaz de crear un paquete sin una contnent. Para superar esto, se decide crear un contenido ficticio que no es visible en la interfaz de usuario, sino que le permite crear un paquete vacío.

Así que la de una sola vez a un paquete w / o contenido fue inválida por tanto, capa de negocio aplicada existencia de contenidos en un objeto de paquete. Eso tiene sentido. Ahora bien, si el escenario del mundo real ha cambiado de tal manera que ahora es una razón válida necesidad de crear objetos de paquete sin contenido, es la capa de lógica de negocio que necesita ser cambiado.

Utilizando casi universalmente "de prueba" en cualquier lugar nada es una mala idea y por lo general indica un problema en la implementación. En este caso está utilizando datos ficticios para permitir el "cumplimiento" con una capa de negocio que ya no representa con precisión las limitaciones del mundo real de los negocios.

Si el paquete sin contenido no es válida, entonces maniquí de datos para permitir "cumplimiento" de la capa de negocio es un truco tonto. En esencia, que escribió las reglas para proteger su propio sistema y entonces, ¿cómo está tratando de eludir su propia protección. Por otra parte si el envase sin contenido es válido capa de negocio, entonces no se debe imponiendo restricciones falsos. En ningún caso es válido datos ficticios.