enumeration - para - que es enum

Mejores prácticas de tablas de búsqueda: Tablas DB... o enumeraciones (8)

¿Es lo único que planea poner en un DB esta lista de empleadores?

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

Los DB son geniales, pero si necesita una clave-valor simple, son excesivos. 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 más adelante, vaya a el DB.

Si tenemos que almacenar los puestos disponibles en una empresa (es decir, Gerente, Jefe de equipo, ... etc.). ¿Cuáles son las mejores prácticas para almacenarlo? Tengo dos opiniones con comentarios ... "seguro, dando la bienvenida a los tuyos"

Guárdelo como una tabla DB con las columnas ID y Nombre, y trátelo mediante consultas y combinaciones.
Almacenándolo como Enum y olvídate de la tabla DB.

En mi opinión, elegiré la primera solución si tengo elementos cambiantes. 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 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".

Búsquedas, búsquedas, búsquedas (inserte el video de baile de monos aquí)

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

Lo mismo ocurre con 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.

Por lo general, solo debe usar la enumeración, donde se trata de 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 tabla de búsqueda en la que potencialmente tiene una gran cantidad de tablas de búsqueda para relaciones simples de id / 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, tendrías 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 Dominios correspondiente a cada tabla de búsqueda que usaría de 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.

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 (por lo general 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 porque 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).

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 facilitará el desarrollo cuando no tenga que recordar el ID de un artículo y también haga 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 tú puedes juzgar el impacto de la cultura de UI, estoy 100% seguro de la cultura de mis usuarios, así que no tienes que preocuparte demasiado :).

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 de padre e 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)

Entonces, 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

Si puedes mantenerlos sincronizados, no creo que haya muchas razones para no tener ambos. 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 de EnumGenerator Visual Studio Addin 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.

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

De " Cinco errores simples en el diseño de la base de datos que debe evitar ":

Si bien la integridad aplicada por la aplicación a veces es favorecida por los desarrolladores, sigue siendo cierto que el DBMS aún debe ser el ejecutor centralizado de toda la 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, una tabla de búsqueda 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, 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 " Diseño de la base de datos y la torre inclinada de Pisa ", el escritor enfatiza por qué es tan importante sentar las bases en una base de datos.

Espero que esto ayude.