¿está bien usar números negativos para extender un modelo de datos estándar de la industria?

7

Estoy trabajando en un proyecto con un cliente que necesita confiar en un conjunto de datos propietarios. También tienen datos personalizados que se ajustan lógicamente a los datos propietarios. Lo que hacen es usar las mismas tablas pero con identificadores negativos. Así que un ejemplo sería

Tabla : Animales

Campos : animal_id, name, can_purr

Por lo tanto, la organización que proporciona los datos proporciona Animals

1, Cat, yes
2, Dog, no
3, Mouse, no

Y luego mi cliente está agregando sus Frankenmals

-1, Werecat, yes
-2, Werewolf, no
-3, Jackalope, no

Para que otros FK de Animal puedan ser reutilizados por Werecat y Jackalope. Cada cierto tiempo, un nuevo animal es reconocido por el mantenedor de datos y agrega, o algo evoluciona hacia una nueva cosa, por lo que es importante mantener las llaves originales. La industria frankenanimal usa esta base de datos y puede entenderme si hablo de Animal 1, pero no si he convertido a Animal 1 en algo que no sea un gato que pueda ronronear. No hay una relación implícita o mantenida entre -2 y 2.

Los números negativos pueden ser la mejor manera de hacerlo. Hace que mi piel se arrastre porque entonces la identificación representa algo más que solo la identificación del registro.

Muchos otros sistemas están cambiando en este momento. Entonces, si este no es un gran diseño, ahora es el momento de cambiarlo.

¿Hay algo tan malo con el enfoque de números negativos? ¿El principal riesgo que veo es si el mantenedor de datos decide usar identificadores negativos para sus propios fines? Una actualización automática podría causar havok. Pero la automatización podría verificar esa condición, entonces, ¿no es tan malo?

Simplemente no puedo encontrar mucho en el camino de los mejores consejos prácticos sobre esto. Entonces, ¿has hecho el enfoque de números negativos y lo lamentaste? ¿Por qué? ¿O se ha transformado en un nuevo esquema y luego lo ha lamentado por mantenimiento o por alguna otra razón?

Mis disculpas si esto es demasiado subjetivo. Simplemente no estoy seguro de cómo descubrir si estoy siendo ilógico o si el doble propósito en la ID de registro es lo suficientemente malo como para merecer un rediseño.

    
pregunta microsaurus_dex 08.05.2018 - 08:40

4 respuestas

5

Desde un punto de vista práctico, lo único que realmente importa es: ¿se garantiza que cada código que acceda a la tabla Animal manejará esos ID negativos correctamente? ¿Tienes el código completamente bajo tu control? Supongo que no, ya que está hablando de un modelo de datos "estándar de la industria", ¿quizás de algún sistema ERP? ¿O puede al menos investigar las partes relevantes del código para entender cómo funciona? Supongo que hay un proveedor tercero involucrado que proporciona software estándar para esto.

Así que verifique la documentación de ese "estándar de la industria": si dice algo así como "se pueden agregar de manera segura las ID negativas para fines de personalización", entonces adelante De lo contrario, incluso ahora funciona, no puede estar seguro de si la próxima versión del software del proveedor externo colisionará con su uso actual. Entonces, si no está 100% seguro de que las identificaciones negativas se pueden usar para lo que está haciendo, presenta un cierto riesgo de romper el sistema de esta manera.

    
respondido por el Doc Brown 08.05.2018 - 11:27
3

Estás trabajando con dos conjuntos de datos. Cualquier intento de ocultar esto y fusionarlos en uno solo tendrá efectos secundarios extraños y es muy probable que conduzca a problemas más adelante.

Mucho mejor tener una base de datos separada con una tabla con las mismas columnas que la original con todos sus frankenimals.

Luego, haga que su conjunto de datos de la aplicación sea consciente y use las tuplas {dataset, row_id} en su aplicación. Esto es agradable, limpio y extensible (ya que puede agregar conjuntos de datos adicionales). También le permitirá en su aplicación trabajar con los conjuntos de datos (por ejemplo, comparar resultados solo para conjuntos de datos oficiales, conjuntos de datos combinados, conjuntos de datos personalizados, etc.).

    
respondido por el Wilbert 08.05.2018 - 18:53
2

No es una gran idea.

La mejor manera es tener su propia ID y vincularla con la ID de datos externos.

Supongamos que tienes una ID de cadena para tu tabla Animal

MyAnimals
MyId,                                 name
230a33e0-ffa4-47ff-9ccb-b3bcf3a33166, Werecat
89f990d5-88eb-4055-b7fe-787cf75d0461, Werewolf


ExternalAnimalLink
MyId,     ExternalDataSetId, ExternalId
"1",      "aniCorp2018",     1
"2",      "aniCorp2018",     2
"wd_2",   "wildData2001",    2

Las desventajas de los números negativos se acercan.

  • ¿Qué pasa si el proveedor externo comienza a usarlos?
  • ¿Qué sucede si necesita un tercer proveedor que también usa números?
  • ¿Qué sucede si los números negativos se utilizan para representar errores (malos pero comunes)?
  • ¿Qué sucede si se utiliza una uint en algún momento o los negativos son inválidos de alguna otra manera?
  • ¿Qué sucede si el número tiene un significado adicional, como ordenar?

Pero también debe considerar los problemas causados por el uso de números para las identificaciones en absoluto.

  • ¿Cuál es la siguiente ID disponible?
  • ¿Cuál es el número máximo de animales alguna vez?
  • ¿Qué pasa con los animales de prueba, obtienen números?
  • ¿El número coincide con el mismo animal en todas las bases de datos?

etc etc

    
respondido por el Ewan 08.05.2018 - 17:01
1

¿La documentación para su estándar discute esto?

En la industria de servicios financieros, es bastante normal ver estándares documentados que permitan extensiones propietarias. Algunos ejemplos de cosas que he visto:

  • No hay facilidades para la extensión, pero se proporcionan una serie de ID "genéricas" para sus propios fines.
  • Las ID que se encuentran debajo de n están reservadas, pero todo lo que esté arriba de n es para datos personalizados.
  • Se permiten números negativos para los campos específicos del cliente.

He visto y usado todos los métodos anteriores, por lo que usar números negativos podría ser una solución viable. Creo que lo importante aquí es revisar la documentación. Si la documentación no especifica ninguna facilidad para las ID personalizadas, entonces valdría la pena mencionarlo con el encargado / comité estándar como una mejora válida. Sin embargo, en última instancia, si el estándar no explícitamente dice que puedes usar números negativos, te arriesgas a romper cosas si otro código (por ejemplo, aplicaciones de terceros) no admite números negativos.

    
respondido por el Karl Nicoll 15.05.2018 - 03:32

Lea otras preguntas en las etiquetas