Usando uma tabela de configuração de linha única no banco de dados do SQL Server. Péssima ideia?

Ao desenvolver um aplicativo de carrinho de compras, descobri que precisava salvar as configurações com base nas preferências e requisitos do administrador. Essas informações podem incluir informações da empresa, IDs de conta de remessa, chaves da API do PayPal, preferências de notificação etc.

Parece altamente inapropriado criar uma tabela para armazenar uma única linha em um sistema de banco de dados relacional.

Qual é a maneira apropriada de armazenar essas informações?

Nota: meu DBMS é o SQL Server 2008 e a camada de programação é implementada com o ASP.NET (em C #).

Eu fiz isso de duas maneiras no passado - uma tabela de linha única e uma tabela de pares de chave / valor - e há pontos positivos e negativos em cada abordagem.

Fila unica

• positivo: os valores são armazenados no tipo correto
• positivo: é mais fácil lidar com o código (devido ao acima)
• positivo: valores padrão podem ser dados para cada configuração individualmente
• negativo: é necessária uma alteração no esquema para adicionar uma nova configuração
• negativo: a tabela pode ficar muito ampla se houver muitas configurações

Par de chave / valor

• positivo: adicionar novas configurações não requer uma alteração no esquema
• positivo: o esquema da tabela é estreito, com linhas extras sendo usadas para novas configurações
• negativo: cada configuração tem o mesmo valor padrão (nulo / vazio?)
• negativo: tudo deve ser armazenado como uma string (por exemplo, nvarchar)
• negativo: ao lidar com as configurações no código, você precisa saber que tipo de configuração é e transmiti-la

A opção de linha única é de longe a mais fácil de se trabalhar. Isso ocorre porque você pode armazenar cada configuração em seu tipo correto no banco de dados e não precisa armazenar os tipos das configurações, bem como suas chaves de pesquisa no código.

Uma coisa que me preocupou em usar essa abordagem foi ter várias linhas na tabela "especial" de configurações de linha única. Eu superei isso por (no SQL Server):

• adicionando uma nova coluna de bits com um valor padrão de 0
• criando uma restrição de verificação para garantir que esta coluna tenha um valor 0
• criando uma restrição exclusiva na coluna de bits

Isso significa que apenas uma linha pode existir na tabela porque a coluna de bits precisa ter um valor 0, mas só pode haver uma linha com esse valor devido à restrição exclusiva.

Você deve criar uma tabela com uma coluna para o tipo de informação e o valor da informação (pelo menos). Dessa forma, você evita a necessidade de criar novas colunas sempre que uma nova informação é adicionada.

Uma única linha funcionará bem; terá até tipos fortes:

show_borders    bit
admin_name      varchar(50)
max_users       int

Uma desvantagem é que requer uma alteração de esquema ( alter table) para adicionar uma nova configuração. Uma alternativa é normalizar, onde você acaba com uma tabela como:

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

Isso tem tipos fracos (tudo é um varchar), mas adicionar uma nova configuração é apenas adicionar uma linha, algo que você pode fazer apenas com acesso de gravação ao banco de dados.

Pessoalmente, eu o armazenaria em uma única linha, se é isso que funciona. Excesso de armazenamento em uma tabela SQL? provavelmente, mas não há nenhum dano real ao fazê-lo.

Como você adivinhou, e, exceto nas situações mais simples, colocar todos os parâmetros de configuração em uma única linha tem muitas desvantagens. Isso é uma má idéia...

Uma maneira conveniente de armazenar informações sobre o tipo de configuração e / ou preferência do usuário é em XML . Muitos DBMSs suportam o tipo de dados XML. A sintaxe XML permite que você gaste a "linguagem" e a estrutura que descrevem a configuração à medida que essa configuração evolui. Uma vantagem do XML é o suporte implícito à estrutura hierárquica, permitindo, por exemplo, armazenar pequenas listas de parâmetros de configuração sem precisar nomeá-los com um sufixo numerado. Uma possível desvantagem do formato XML é que a pesquisa e a modificação geral desses dados não são tão diretas quanto outras abordagens (nada complicado, mas não tão simples / natural)

Se você deseja permanecer mais próximo do modelo relacional , o modelo de Entidade-Atributo-Valor é provavelmente o que você precisa, pelo qual os valores individuais são armazenados em uma tabela que normalmente se parece com:

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)

Em que o AttributeId é uma chave estrangeira para uma tabela na qual cada atributo possível ("parâmetro de configuração" no seu caso) é definido, por exemplo

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, o EntityId permite identificar alguma entidade que "possui" esses vários atributos. No seu caso, pode ser um UserId ou mesmo implícito se você tiver apenas uma configuração para gerenciar.

Além de permitir que a lista de possíveis parâmetros de configuração cresça à medida que a aplicação evolui, o modelo EAV coloca os "metadados", ou seja, os dados pertencentes ao próprio Atributo, nas tabelas de dados, evitando assim toda a codificação codificada dos nomes de colunas comumente vistos quando os parâmetros de configuração são armazenados em uma única linha.

Você certamente não precisa alterar seu esquema ao adicionar um novo parâmetro de configuração na abordagem normalizada, mas provavelmente ainda está alterando seu código para processar o novo valor.

A adição de uma "tabela alterada" à sua implantação não parece ser uma grande desvantagem pela simplicidade e segurança de tipo da abordagem de linha única.

Um par de Chave e Valor é semelhante a um .Net App.Config que pode armazenar definições de configuração.

Então, quando você deseja recuperar o valor, pode:

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

Uma maneira comum de fazer isso é ter uma tabela de "propriedades" semelhante a um arquivo de propriedades. Aqui você pode armazenar todas as constantes do seu aplicativo, ou coisas não tão constantes que você só precisa ter por perto.

Você pode pegar as informações desta tabela conforme necessário. Da mesma forma, como você encontra alguma outra configuração para salvar, pode adicioná-la. Aqui está um exemplo:

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"   

Dessa forma, você pode armazenar os dados que possui e os que terá no próximo ano e ainda não sabe :).

Neste exemplo, seu escopo e refId podem ser usados ​​para o que você quiser no back-end. Portanto, se o propertyType "ADMIN" tiver um escopo 0 refId 2, você saberá qual é a preferência.

O tipo de propriedade é fornecido quando, um dia, você precisar armazenar informações não administrativas aqui também.

Observe que você não deve armazenar dados do carrinho dessa maneira ou fazer pesquisas para esse assunto. No entanto, se os dados forem específicos do sistema , você certamente poderá usar esse método.

Por exemplo: se você deseja armazenar seu DATABASE_VERSION , use uma tabela como esta. Dessa forma, quando você precisar atualizar o aplicativo, poderá verificar a tabela de propriedades para ver qual versão do seu software o cliente possui.

O ponto é que você não deseja usar isso para coisas que pertencem ao carrinho. Mantenha sua lógica de negócios em tabelas relacionais bem definidas. A tabela de propriedades é apenas para informações do sistema.

Não tenho certeza se uma única linha é a melhor implementação para configuração. É melhor ter uma linha por item de configuração com duas colunas (configName, configValue), embora isso exija a conversão de todos os seus valores para strings e vice-versa.

Independentemente disso, não há mal nenhum em usar uma única linha para a configuração global. As outras opções para armazená-lo no DB (variáveis ​​globais) são piores. Você pode controlá-lo inserindo sua primeira linha de configuração e desativando as inserções na tabela para evitar várias linhas.

Você pode fazer o par de chave / valor sem conversões adicionando uma coluna para cada tipo principal e uma coluna informando em qual coluna os dados estão.

Portanto, sua tabela seria algo como:

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, 

Ele ocupa um pouco mais de espaço, mas no máximo você está usando algumas dezenas de atributos. Você pode usar uma declaração de caso do valor column_num para obter / ingressar no campo direito.

Desculpe eu venho, anos depois. De qualquer forma, o que faço é simples e eficaz. Eu simplesmente crio uma tabela com três () colunas:

ID - int (11)

nome - varchar (64)

valor - texto

O que eu faço antes de criar uma nova coluna de configuração, atualizá-la ou ler é serializar o "valor"! Dessa forma, tenho certeza do tipo (Bem, php é :))

Por exemplo:

b: 0; é para B OOLEAN ( falso )

b: 1; é para B OOLEAN ( verdadeiro )

i: 1988; é para eu NT

s: 5: "Kader"; é para um S TRING de 5 caracteres

Eu espero que isso ajude :)

Tenha uma coluna de chave como varchar e uma coluna de valor como JSON. 1é numérico enquanto "1"é uma sequência. truee falsesão ambos booleanos. Você pode ter objetos também.