No nulo claves externas como Standard Base de Datos

Question

Antecedentes: En la actualidad, se planteó la cuestión durante el uso de SQL Server Reporting Services. Parece que los parámetros desplegables SSRS en el visor de informes no le permiten indicar una opción (nulo) de manera que se puede ver un informe en el que el parámetro es nulo. Básicamente, el cuadro A es un cuadro de correspondencia entre nullably la tabla B; ya que el informe utiliza la tabla B para poblar el desplegable, no hay valores nulos para mostrar como una opción, y por lo tanto no se pueden seleccionar todos los de la A que tiene un nulo B.

Mi verdadera pregunta es desde el potencial reacción inmediata al problema anterior por un tipo de gestión a la que estoy respondiendo. Cuando le expliqué lo que estaba pasando, se emitió un nuevo mandato que todas las claves externas deben ser no nulo y que cada entidad debe tener un registro "por defecto" insertado, un nuevo estándar aparentemente para resolver este problema en la herramienta de informes. Básicamente, si usted tiene una mesa de gato, entonces Cat.Owner nunca debe ser nula, sino que debe hacer referencia a un registro por omisión en la tabla Persona, la "default".

Si bien esto puede ayudar con el problema de SSRS, que puede doler desarrollo / mantenimiento de los servicios y aplicaciones que utilizan la base de datos, desde que habían ahora no sólo tienen que dar cuenta de los nulos (que se dejaron a este punto), pero también tienen aspecto de y utilizar correctamente el registro "por defecto". Pensé en tratar de hablar con ella fuera del mandato, pero me gustaría recoger alguna información de la experiencia antes de que decida hacerlo.

¿Alguien puede opinar sobre lo que esto puede ayudar o perjudicar?

Cualquier persona tenía esto como un estándar de base de datos? Cualquier cuestiones, el desarrollo o de lo contrario, deben ser mindfull de?

Answer 1

campos NULL significan valor .

Así que es lógico y correcto para llenar relación faltante con nulos.

he visto, a veces, en algunos casos especiales, el uso de un de grabación predeterminado como se describe en la pregunta. Pero eso era un "caso especial" y se usa "a veces".

En mi humilde opinión obligando a esta política como un estándar Desarrollos DB es simplemente tonto, incorrecta y potencialmente peligroso. Yo no aventura en todas las posibles complicaciones que surgen de este tipo de diseño: supongo que ya se imagina lo que eso significaría

.

Answer 2

Mientras que, si el gato es un OWNED_CAT, entonces debe tener una persona como el propietario, si se abandona, no debería estar en esa mesa.

Sin embargo, si el gato es un ANY_CAT (con / sin propietario), a continuación, que abandonó CAT no debe asociarse con cualquier persona.

Para mí, la creación de un maniquí o registro predeterminada en la tabla PERSONA por el bien de la notificación tiene sentido empresarial (por su administrador), pero no me siento 'derecho' al respecto.

No se puede ofrecer mucho, sólo mis 2 centavos.