sql - guia - qgis manual

Usando una tabla de configuración de una sola fila en la base de datos de SQL Server. ¿Mala idea?

Question

Al desarrollar una aplicación de carrito de compras, descubrí que necesitaba guardar configuraciones y configuraciones en función de las preferencias y los requisitos del administrador. Esta información puede ser cualquier cosa, desde información de la empresa, ID de cuenta de envío, claves API de PayPal, preferencias de notificación, etc.

Parece muy inapropiado crear una tabla para almacenar una sola fila en un sistema de base de datos relacional.

¿Cuál es la forma apropiada de almacenar esta información?

Nota: mi DBMS es SQL Server 2008 y la capa de programación está implementada con ASP.NET (en C #).

Answer 1

Como has adivinado, y salvo en las situaciones más simples, poner todos los parámetros de configuración en una sola fila tiene muchos inconvenientes. Es una mala idea ...

Una forma conveniente de almacenar la configuración y / o el tipo de información de preferencia del usuario es en XML . Muchos DBMS respaldan el tipo de datos XML. La sintaxis XML le permite utilizar el "idioma" y la estructura que describe la configuración a medida que evoluciona esta configuración. Una ventaja de XML es su soporte implícito para la estructura jerárquica, que permite, por ejemplo, almacenar pequeñas listas de parámetros de configuración sin tener que nombrarlos con un sufijo numerado. Una posible desventaja del formato XML es que la búsqueda y, en general, la modificación de estos datos no es tan directa como otros enfoques (nada complicado, pero no tan simple / natural)

Si desea permanecer más cerca del modelo relacional , el modelo Entidad-Valor-Atributo es probablemente lo que necesita, por lo que los valores individuales se almacenan en una tabla que generalmente se ve así:

EntityId     (foreign key to the "owner" of this attribute)
AttributeId  (foreign key to the "metadata" table where the attribute is defined)
StringValue  (it is often convenient to have different columns of different types
IntValue      allowing to store the various attributes in a format that befits 
              them)

Por lo que AttributeId es una clave externa a una tabla donde se define cada Atributo posible ("parámetro de configuración" en su caso), con decir

AttributeId  (Primary Key)
Name
AttributeType     (some code  S = string, I = Int etc.)
Required          (some boolean indicating that this is required)
Some_other_fields   (for example to define in which order these attributes get displayed etc...)

Finalmente, EntityId le permite identificar alguna entidad que "posee" estos diversos atributos. En su caso, podría ser un UserId o incluso simplemente implícito si solo tiene una configuración para administrar.

Además de permitir que la lista de posibles parámetros de configuración crezca a medida que la aplicación evoluciona, el modelo EAV coloca los "metadatos", es decir, los datos pertenecientes a los Atributos mismos, en tablas de datos, evitando así toda codificación difícil de los nombres de columna comúnmente vistos cuando los parámetros de configuración están almacenados en una sola fila.

Answer 2

Debe crear una tabla con una columna para el tipo de información y el valor de la información (al menos). De esta forma, evitará tener que crear nuevas columnas cada vez que se agregue una nueva información.

Answer 3

He hecho esto de dos maneras en el pasado: una sola tabla de filas y una tabla de pares clave / valor, y hay aspectos positivos y negativos para cada enfoque.

Unica fila

• positivo: los valores se almacenan en el tipo correcto
• positivo: es más fácil de tratar en el código (debido a lo anterior)
• positivo: los valores predeterminados se pueden dar a cada ajuste individualmente
• negativo: se requiere un cambio de esquema para agregar una nueva configuración
• negativo: la tabla puede llegar a ser muy amplia si hay muchas configuraciones

Par clave / valor

• positivo: agregar nuevas configuraciones no requiere un cambio de esquema
• positivo: el esquema de la tabla es estrecho, con filas adicionales que se utilizan para nuevas configuraciones
• negativo: cada configuración tiene el mismo valor predeterminado (nulo / vacío?)
• negativo: todo tiene que almacenarse como cadenas (es decir, nvarchar)
• negativo: al tratar con la configuración en el código, debe saber qué tipo de configuración es y emitirla

La opción de una sola fila es, con mucho, la más fácil de trabajar. Esto se debe a que puede almacenar cada configuración en su tipo correcto en la base de datos y no tener que almacenar los tipos de configuración, así como sus claves de búsqueda en el código.

Una cosa que me preocupaba con el uso de este enfoque era tener varias filas en la tabla de configuraciones de una sola fila "especial". Superé esto por (en SQL Server):

• agregando una nueva columna de bit con un valor predeterminado de 0
• creando una restricción de verificación para asegurar que esta columna tenga un valor de 0
• creando una restricción única en la columna de bit

Esto significa que solo puede existir una fila en la tabla porque la columna de bits debe tener un valor de 0, pero solo puede haber una fila con ese valor debido a la restricción única.

Answer 4

No es necesario que cambie su esquema al agregar un nuevo parámetro de configuración en el enfoque normalizado, pero probablemente aún esté cambiando su código para procesar el nuevo valor.

Agregar una "tabla alternativa" a su implementación no parece una gran compensación para la simplicidad y la seguridad del tipo del enfoque de una sola fila.

Answer 5

No estoy seguro de que una sola fila sea la mejor implementación para la configuración. Puede que sea mejor tener una fila por elemento de configuración con dos columnas (configName, configValue), aunque esto requerirá convertir todos sus valores a cadenas y viceversa.

De todos modos, no hay daño al usar una sola fila para la configuración global. Las otras opciones para almacenarlo en el DB (variables globales) son peores. Puede controlarlo insertando su primera fila de configuración y deshabilitando las inserciones en la tabla para evitar filas múltiples.

Answer 6

Perdón por haber venido, tarde después. Pero de todos modos, lo que hago es simple y efectivo. Simplemente creo una tabla con tres () columnas:

ID - int (11)

nombre - varchar (64)

valor - texto

Lo que hago antes de crear una nueva columna de configuración, actualizarla o leer es serializar el "valor". De esta manera estoy seguro del tipo (Bueno, php es :))

Por ejemplo:

b: 0; es para B OOLEAN ( falso )

b: 1; es para B OOLEAN ( verdadero )

i: 1988; es para I NT

s: 5: "Kader"; es para un S TRING de 5 caracteres de longitud

Espero que esto ayude :)

Answer 7

Personalmente, lo almacenaría en una sola fila si eso es lo que funciona. Overkill para almacenarlo en una tabla SQL? probablemente, pero no hay daño real al hacerlo.

Answer 8

Puede hacer el par clave / valor sin conversiones agregando una columna para cada tipo principal y una columna que le indique en qué columna se encuentran los datos.

Entonces su mesa se vería así:

id, column_num, property_name, intValue, floatValue, charValue, dateValue
1, 1, weeks, 51, , ,
2, 2, pi, , 3.14159, , 
3, 4, FiscYearEnd, , , , 1/31/2015
4, 3, CompanyName, , , ACME, 

Utiliza un poco más de espacio, pero a lo sumo está usando unas pocas docenas de atributos. Puede usar un enunciado de caso fuera del valor de column_num para tirar / unir el campo derecho.

Answer 9

Tener una columna de clave como varchar y una columna de valor como JSON. 1 es numérico, mientras que "1" es una cadena. true y false son ambos booleanos. También puedes tener objetos.

Answer 10

Un par de clave y valor es similar a .Net App.Config, que puede almacenar configuraciones de configuración.

Entonces, cuando desee recuperar el valor que podría hacer:

SELECT value FROM configurationTable
WHERE ApplicationGroup = ''myappgroup''
AND keyDescription = ''myKey'';

Answer 11

Una forma común de hacer esto es tener una tabla de "propiedades" similar a un archivo de propiedades. Aquí puede almacenar todas las constantes de su aplicación, o cosas no tan constantes que solo necesita tener.

A continuación, puede tomar la información de esta tabla cuando lo necesite. Del mismo modo, cuando encuentre que tiene alguna otra configuración para guardar, puede agregarla. Aquí hay un ejemplo:

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "COMPANY_INFO", "Acme Tools", "ADMIN"  
2, 0, 1, "SHIPPING_ID", "12333484", "ADMIN"  
3, 0, 1, "PAYPAL_KEY", "2143123412341", "ADMIN"   
4, 0, 1, "PAYPAL_KEY", "123412341234123", "ADMIN"  
5, 0, 1, "NOTIF_PREF", "ON", "ADMIN"  
6, 0, 2, "NOTIF_PREF", "OFF", "ADMIN"   

De esta forma puede almacenar los datos que tiene y los datos que tendrá el próximo año y que aún no conoce :).

En este ejemplo, su alcance y refId se pueden usar para lo que quiera en el back-end. Entonces, si propertyType "ADMIN" tiene un alcance 0 refId 2, usted sabe de qué preferencia se trata.

El tipo de propiedad viene a la mano cuando, algún día, necesita almacenar información que no sea de administrador aquí también.

Tenga en cuenta que no debe almacenar los datos del carrito de esta manera o las búsquedas para el caso. Sin embargo, si los datos son específicos del sistema , entonces ciertamente puede usar este método.

Por ejemplo: si desea almacenar su DATABASE_VERSION , usaría una tabla como esta. De esta forma, cuando necesite actualizar la aplicación, puede consultar la tabla de propiedades para ver qué versión de su software tiene el cliente.

El punto es que no quiere usar esto para cosas que pertenecen al carrito. Mantén tu lógica de negocio en tablas relacionales bien definidas. La tabla de propiedades es solo para información del sistema.

Answer 12

Una sola fila funcionará bien; incluso tendrá tipos fuertes:

show_borders    bit
admin_name      varchar(50)
max_users       int

Una desventaja es que requiere un cambio de esquema ( alter table ) para agregar una nueva configuración. Una alternativa es normalizar, donde terminas con una tabla como:

pref_name       varchar(50) primary key
pref_value      varchar(50) 

Esto tiene tipos débiles (todo es varchar), pero agregar una nueva configuración es simplemente agregar una fila, algo que se puede hacer solo con el acceso de escritura de la base de datos.