Mejores prácticas de tablas de búsqueda: Tablas DB ... o Enumeraciones

Question

Si tenemos que almacenar las posiciones disponibles en una empresa (es decir, Manager, Team Lead, ... etc.). ¿Cuáles son las mejores prácticas para almacenarlo? Tengo dos opiniones con los comentarios ... "claro, bienvenida la suya"

1. almacenarla como tabla de base de datos con las columnas ID y Nombre, y tratar con él utilizando consultas y conexiones.
2. Almacenándolo como Enum y olvídese de la tabla DB.

En mi opinión, voy a elegir la primera solución si he de cambiar artículos. Para no codificar estas opciones como Enum.
Puedo elegir la solución Enum, si no tengo dudas de que los datos no cambiarán (por ejemplo, Género: Masculino, Femenino).

NOTA: código en inglés, y la cultura de la interfaz de usuario puede ser árabe. Si voy a trabajar con la solución Enum, voy a codificar las cadenas basadas en cultura en la capa de presentación, ¿está bien desde la perspectiva de las mejores prácticas?

Me gustaría conocer sus opiniones y si mis pensamientos corresponden a lo que más se recomienda como "Mejores prácticas" ??

Answer 1

Tiendo a ir por la opción de base de datos ya que esto permite consultar fácilmente con datos significativos (es decir, nombres en lugar de ID).

Si estoy bastante seguro de que los valores no cambiarán, los enumeraré en la aplicación y también facilitará el desarrollo cuando no tenga que recordar el ID de un artículo y también hace que el código sea mucho más legible .

Este enfoque me permite elegir si incluir la tabla de búsqueda en las consultas o no. Por ejemplo, lo incluiría en una consulta de informe en la que deseo mostrar el valor de búsqueda, pero puede que no lo incluya cuando cargue datos en mi aplicación si puedo inferirlo de la enumeración.

Obviamente, si los valores están sujetos a cambios o modificaciones, la enumeración puede no ser posible.

Solo usted puede juzgar el impacto de la cultura de la interfaz de usuario, estoy 100% seguro de la cultura de mis usuarios, así que no tiene que preocuparse demasiado :).

Answer 2

búsquedas, búsquedas, búsquedas (vídeo mono-baile del relleno aquí)

Mi personal "mejor práctica" es tener todo en la base de datos. Las posiciones en una empresa definitivamente son una tabla de búsqueda.

Lo mismo vale para las traducciones, que pueden ser un poco más complicadas, pero en general una definición de vista que une la tabla con una tabla de traducción es un buen comienzo.

Además, si la Posición es solo un valor int, y su aplicación es de un solo idioma, puede agregar los títulos de posición directamente a la base de datos.

Answer 3

Por lo general, solo debe usar la enumeración donde se muestra un conjunto claro de elementos que no cambiará. Hombre/Mujer es un buen ejemplo; de lo contrario, las tablas de búsqueda, con claves externas implementadas apropiadamente, son casi siempre la mejor opción.

Existe una posible variación en la opción de la tabla de búsqueda en la que posiblemente tenga una gran cantidad de tablas de búsqueda para relaciones sencillas de identificación/valor. Un par de tabla de dominio/búsqueda puede reducir drásticamente esta cantidad de tablas requeridas, aunque con cierta complejidad de codificación adicional. En este caso usted tendría una tabla de dominio

 
DomainID int identity 
Domain varchar(255) 

y una tabla de clave/valor

 
DomainID int 
ID  int identity 
Value varchar(255) 

Por lo tanto se agrega una fila a la tabla de dominio correspondiente a cada tabla de búsqueda que usted utilizaría otra manera

, y todos los pares (de dominio clave)/valor agregados a la tabla de valores. Además de simplificar la estructura de la base de datos, este enfoque también tiene la ventaja de que las 'tablas de búsqueda' se pueden crear dinámicamente en el código de la aplicación, lo que en algunas aplicaciones puede ser extremadamente útil.

Answer 4

Tiendo a casi siempre poner este tipo de cosas en una mesa. Si es necesario, lo guardaré en caché. Si necesito referirme programáticamente a algunos de ellos, crearé una enumeración que tiene sus valores establecidos en el valor clave del elemento de búsqueda.

Por ejemplo, una clave primaria sustituta (generalmente mi capa de acceso a datos puede agregarla/actualizarla), un campo para el valor del elemento más un "candidato" (el candidato está entre comillas ya que no es obligatorio; por lo que es único o nulo). De esa forma puedo usar la enumeración entre comillas para referirme a elementos específicos/importantes en la tabla, pero aún tengo la flexibilidad de permitir que los usuarios finales agreguen nuevos elementos. Los detalles del modelo de datos utilizados realmente dependen de sus preferencias (algunas personas pueden estar gritándome en este momento no solo al usar el campo "candidato" como la verdadera clave principal).

Answer 5

¿Es la única cosa que planea poner en una base de datos de esta lista de empleadores?

En caso afirmativo, colóquelo en un archivo y termine con él.

Las bases de datos son geniales, pero si necesita una clave de valor simple, son excesivas. Te dan muchas cosas. Pero también hacen muchas cosas detrás de escena, son una cosa más que necesitas apoyar ... si puedes salirte con la tuya con un único archivo con 20 líneas delimitadas por tabuladores, ve con sencillez.

Si tiene muchas cosas que requieren este tipo de búsquedas, o si cree que podría necesitar actualizarlas mientras un cliente intenta leerlas, o si desea hacer una referencia cruzada de las cosas más adelante, - luego ve por el DB.

Answer 6

Siempre busco la opción de base de datos ya que tiene varias ventajas, una de las principales es que puede cambiar los nombres/descripciones de los elementos en las listas de búsqueda sin tener que cambiar ningún código. También acuerde con tener una sola tabla en lugar de muchas tablas pequeñas, de esa manera codifica una única rutina para recuperar los valores de la base de datos, lo que reduce los costos de mantenimiento. Tener una sola rutina significa que puede invertir más esfuerzo para hacerlo funcionar bien.

Además de la respuesta de Cruachan anterior, puede salirse con la suya con una tabla si tiene una relación padre-hijo en la que las filas sin padre describen el dominio. Todos los registros que pertenecen a un dominio tienen la fila de dominio como su padre.

ID   int autonumber -- integer primary key for performance 
DomainID  int   -- null for domains 
Name   varchar(100) -- Name of the item 
Description varchar(255) 

Así, por ejemplo, una lista de monedas podría contener:

ID DomainID Name    Description 

100 NULL  ISO Currencies List of ISO Currency codes 
101 100  BHD    Bahrain Dinar 
102 100  GBP    British Pound 
103 100  EUR    Euro 
104 100  USD    US Dollar 

Answer 7

Si puede mantenerlos sincronizados no creo que hay mucho de una razón para no tener ambas cosas.Cuando estaba desarrollando alguna funcionalidad de máquina de estado con un almacén de DB, era mucho más fácil tener una enumeración de los estados de objeto disponibles dentro de mi IDE.

Me escribí un poco EnumGenerator Visual Studio Añadiendo hace un tiempo que crea un fragmento de código Enumeration en C# desde las columnas ID y DESC de un DB Tablet que seleccionas desde el IDE. No lo publiqué porque era la primera vez que trabajaba con los complementos de VS y fue bastante chatarra, pero apuesto a que alguien con experiencia en la generación de complementos/códigos podría tomar la idea y correr con ella.

Answer 8

Opción 1: Almacenarla como tabla de DB con columnas ID y Nombre, y tratar con consultas y uniones es lo mínimo que debe hacer.

De "Five Simple Database Design Errors You Should Avoid":

Mientras integridad de la aplicación forzada a veces se ve favorecida por los desarrolladores, sigue siendo cierto que el DBMS debe seguir siendo el ejecutor centralizada de toda integridad.

La mejor práctica recomendada es implementar su base de datos como si no supiera nada sobre la interfaz de usuario. Es decir, la base de datos debe hacer cumplir todas las reglas relacionadas con los datos; en este caso, la base de datos debe hacer cumplir los valores que sean apropiados. Para enumerar qué valores son apropiados, un lookup table para cada tipo de valor de búsqueda suele ser el camino a seguir. Muchas veces, las aplicaciones van y vienen, pero la base de datos permanece y se vuelve a usar.

Si desea imponer enumeraciones en la aplicación, sin duda puede hacerlo, pero haga lo que haga, asegúrese de que la base de datos haga su trabajo como una base de datos y mantenga la integridad de los datos. Si es problemático, ve por el problema; estás sentando las bases. En "Database Design and the Leaning Tower of Pisa", el escritor enfatiza por qué es tan importante sentar las bases en una base de datos.

Espero que esto ayude.