Como você estrutura de dados de configuração em um banco de dados?

Question

O que é o método preferido das pessoas de armazenar dados de configuração do aplicativo em um banco de dados. De ter feito isso no passado eu mesmo, eu tenho utilizado duas maneiras de fazê-lo.

1. Você pode criar uma tabela onde você armazena pares de chave / valor, onde chave é o nome da opção de configuração e valor é o seu valor. Pro de esta é a adição de novos valores é fácil e você pode usar as mesmas rotinas de set / get dados. Desvantagens são que você tem dados sem tipo como o valor.
2. Como alternativa, você pode codificar uma tabela de configuração, com cada coluna sendo o nome do valor e seu tipo de dados. A desvantagem para isso é mais a criação de novos valores de manutenção, mas permite que você tenha dados digitados.

Tendo usado tanto, minhas preferências deitar com a primeira opção como seu mais rápido para as coisas configurar, no entanto a sua também mais arriscado e pode reduzir o desempenho (ligeiramente) quando olhando para cima de dados. Alguém tem alguma métodos alternativos?

Atualizar

É necessário armazenar as informações em um banco de dados porque, como observado abaixo, pode haver várias instâncias do programa que exigem configuração da mesma forma, assim como procedimentos armazenados, potencialmente, usando os mesmos valores.

Answer 1

Você pode expandir a opção 1 para ter uma 3ª coluna, dando um tipo de dados. Sua lata de aplicação do que o uso desta coluna do tipo de dados para converter o valor.

Mas sim, eu iria com a opção 1, se os arquivos de configuração não são uma opção. Outra vantagem da opção 1 é que você pode lê-lo em um objeto Dictionary (ou equivalente) para uso em sua aplicação realmente facilmente.

Answer 2

Uma vez que a configuração normalmente podem ser armazenados em um arquivo de texto, o tipo de dados de cadeia deve ser mais do que suficiente para armazenar os valores de configuração. Se você estiver usando uma linguagem gerenciada, é o código que sabe o que o tipo de dados deve ser, não o banco de dados.

Mais importante, considere essas coisas com a configuração:

• Hierarquia : Obviamente, a configuração irá beneficiar de uma hierarquia
• Versioning :. Considere o benefício de ser capaz de reverter para a configuração que estava em vigor em uma determinada data
• Distribuição : Algum tempo, que poderia ser bom para ser capaz de agrupar um aplicativo. Algumas propriedades provavelmente deve ser local para cada nó em um cluster.
• Documentação : Dependendo se você tem uma ferramenta de web ou algo assim, é provavelmente bom para armazenar a documentação sobre uma propriedade perto do código que o utiliza. (Anotações código é muito bom para isso.)
• Notificação : Como está o código vai saber que uma alteração foi feita em algum lugar no repositório de configuração

pessoalmente, como uma forma de configuração invertida manuseamento, onde as propriedades de configuração é injectado nos módulos que não sabe onde os valores veio. Desta forma, o sistema de gerenciamento de configuração pode ser muito complexa ou muito simples, dependendo de suas necessidades (correntes).

Answer 3

Eu uso a opção 1.

Answer 4

Parece exagero para usar o DB para de dados de configuração.

EDIT (desculpe muito tempo para caixa de comentário): Claro que há há regras rígidas sobre como você implementar qualquer parte do seu programa. Por uma questão de argumento, chaves de fenda com fenda trabalho em algum Philips parafusos! Eu acho que eu julguei muito cedo antes de saber o que o seu cenário é.

sobressai de banco de dados relacionais no armazenamento de dados em massa que lhe dá armazenamento rápida, atualização e recuperação, por isso, se os seus dados de configuração é atualizado e ler constantemente, em seguida, por todos os meios usar db.

Outro cenário em que db pode fazer sentido é quando você tem uma fazenda de servidor onde você quer que seu banco de dados para armazenar sua configuração central, mas então você pode fazer o mesmo com uma unidade de rede compartilhada que apontam para o arquivo XML de configuração.

arquivo XML é melhor quando sua configuração é estruturado hierarquicamente. Você pode facilmente organizar, localizar e atualizar o que você precisa, e para o benefício do bônus você pode controle de versão do arquivo de configuração, juntamente com seu código-fonte!

Em suma, tudo depende de como os dados de configuração é usado.

Isso conclui minha opinião com conhecimento limitado de sua aplicação. Tenho certeza que você pode tomar a decisão certa.

Answer 5

Eu acho que esta é mais uma pesquisa, então eu vou dizer a abordagem coluna (opção 2). No entanto, vai depender de quantas vezes as alterações de configuração, como dinâmica que é, e quantos dados existe, etc.

Eu certamente usar essa abordagem para configurações de usuário / preferências, etc.

Answer 6

Meu projeto usa uma tabela de banco de dados com quatro colunas:

1. ID [pk]
2. Scope (default 'Aplicação')
3. Configuração
4. Valor

Configurações com um escopo de 'aplicação' são configurações globais, tais como o número máximo de usuários simultâneos.

Cada módulo tem seu próprio escopo com base; por isso a nossa ResultsLoader e UserLoader tenham objetivos diferentes, mas ambos têm uma configuração chamada 'inputPath'.

Padrões ou são fornecidos no código de fonte ou são injectados com o nosso recipiente CIO. Se nenhum valor é injectado ou fornecida na base de dados, o padrão do código é usada (se existir). Portanto, os padrões nunca são armazenados no banco de dados.

Isso funciona muito bem para nós. Cada vez que o backup do banco de dados nós temos uma cópia da configuração que é bastante útil. Os dois estão sempre em sincronia.

Answer 7

Vá com a opção 2. Opção 1 é realmente uma maneira de implementar um banco de dados em cima de um banco de dados, e que é um conhecido anti padrão, que só vai dar-lhe problemas no longo prazo.

Answer 8

Não consigo pensar em mais pelo menos duas maneiras:

(a) Criar uma tabela com chave, cadeia de valor, a data-valor, int valor, colunas de valor real. Deixe não utilizado tipos NULL.

(b) Use um formato de serialização como XML, YAML ou JSON e armazenar tudo em uma bolha.

Answer 9

Onde você armazenar as definições de configuração às suas necessidades de aplicativos para se conectar ao banco de dados?

Por que não armazenar a outra informação de configuração lá também?

Answer 10

Eu iria com a opção 1, a menos que o número de opções de configuração foram muito pequenas (sete ou menos)

Answer 11

Na minha empresa, estamos trabalhando com a opção um (um dicionário-como simples tabela) com uma torção. Estamos permitindo a substituição de string usando fichas que contêm o nome da variável de configuração para ser substituído.

Por exemplo, a tabela pode conter linhas ( 'banco de dados de conexão string', 'jdbc: //% host% ...') e ( 'host', 'foobar'). O encapsulamento de que com um serviço simples ou camada procedimento armazenado permite uma configuração extremamente simples, mas flexível, recursiva. Ele suporta a nossa necessidade de ter vários ambientes isolados (dev, teste, prod, etc).

Answer 12

Eu usei tanto 1 e 2, no passado, e eu acho que eles são ambas as soluções terríveis. Eu acho que a opção 2 é melhor porque permite digitação, mas é muito mais feio do que a opção 1. O maior problema que tenho com qualquer um é de versão do arquivo de configuração. Você pode versão SQL razoavelmente bem usando sistemas de controle de versão padrão, mas mesclar as alterações geralmente é problemático. Dada a oportunidade de fazer isso "direito", eu provavelmente criar um monte de tabelas, uma para cada tipo de parâmetro de configuração (não necessariamente para cada parâmetro em si), obtendo assim o benefício de digitação e o benefício da chave / valor paradigma, quando apropriado. Você também pode implementar estruturas mais avançadas desta forma, como listas e hierarquias, que depois serão consultáveis ??diretamente pelo aplicativo, em vez de ter que carregar a configuração e, em seguida, transformá-lo de alguma forma na memória.

Answer 13

votação I para a opção 2. Fácil de entender e manter.

Answer 14

A opção 1 é bom para, um local de armazenamento central facilmente expansível. Além de alguns dos grandes sugestões de coluna por pessoas como RB, Hugo, e Elliott, você pode também considerar:

Inclua uma bandeira cenário global / usuário com um campo de usuário ou até mesmo um campo de usuário / máquina (para configurações de tipo de interface do usuário específicos da máquina).

Aqueles pode, naturalmente, ser armazenadas em um arquivo local, mas desde que você está usando o banco de dados de qualquer maneira, que faz estes disponíveis para aliasing um usuário quando a depuração - o que pode ser importante se o bug está definindo relacionados. Ele também permite que um administrador para gerenciar setings quando necessário.

Answer 15

Eu uso uma mistura das opções 2 e XML colunas no servidor SQL. Você também pode wan't para adicionar uma restrição de verificação para manter a tabela em uma linha.

CREATE TABLE [dbo].[MyOption] (
  [GUID] uniqueidentifier CONSTRAINT [dfMyOptions_GUID] DEFAULT newsequentialid()  ROWGUIDCOL NOT NULL,
  [Logo] varbinary(max) NULL,
  [X] char(1)  CONSTRAINT [dfMyOptions_X] DEFAULT 'X' NOT NULL,
  CONSTRAINT [MyOptions_pk] PRIMARY KEY CLUSTERED ([GUID]),
  CONSTRAINT [MyOptions_ck] CHECK ([X]='X')
)

Answer 16

para as configurações que não têm relação com nenhum tabelas db, eu provavelmente ir para a abordagem EAV se você precisa do db para o trabalho com os valores. caso contrário, um valor de campo serializado é bom se ele é realmente apenas uma loja para código do aplicativo.

mas que sobre um formato para um único campo para armazenar várias definições de configuração a ser usado pelo db?

como um campo por usuário que contém todas as suas definições relacionadas com a sua visão messageboard (como ordem de classificação padrão, bloqueou temas, etc.), e talvez outro com todas as suas configurações para seu tema (como a cor do texto, cor bg, etc .)

Answer 17

O armazenamento hierarquia e documentos em um banco de dados relacional é loucura. Em primeiro lugar você tem que destrui-los, apenas para recombinar-los em algum momento mais tarde. Ou há bunged dentro de um BLOB, ainda mais estúpido.

Não use usar um banco de dados relacional para dados não-relacionais, a ferramenta não se encaixa. Considere algo como MongoDB ou CouchDB para isso. Sem esquema não-relacionais armazena os dados. Armazená-lo como JSON se ele está descendo o fio de alguma forma para um cliente, o uso de XML para serverside.

CouchDB oferece versões para fora da caixa.

Answer 18

Não armazenar dados de configuração em um banco de dados a menos que você tenha uma boa razão para isso. Se você tem uma razão muito boa, e está absolutamente certo de que você está indo para fazê-lo, você provavelmente deve armazená-lo em um formato de serialização de dados como JSON ou YAML (não XML, a menos que você realmente precisa de uma linguagem de marcação para configurar seu aplicativo - - confie em mim, você não) como uma string. Depois, é só ler a cadeia, e usar ferramentas em qualquer língua em que trabalha para ler e modificá-lo. Armazenar as cordas com marcas de tempo, e você tem um esquema simples de versionamento com a capacidade de armazenar dados hierárquicos em um sistema muito simples. Mesmo se você não precisa de dados de configuração hierárquica, pelo menos agora se você precisar dele no futuro, você não terá que mudar sua interface de configuração para obtê-lo. Claro que você perde a capacidade de fazer consultas relacionais em seus dados de configuração, mas se você está armazenando que dados de configuração muito, então provavelmente você está fazendo algo muito errado de qualquer maneira.

As empresas tendem a armazenar dados de configuração lotes para os seus sistemas em um banco de dados, eu não sei por que, eu não penso muito pensamento vai para essas decisões. Eu não vejo esse tipo de coisa feita muitas vezes no mundo OSS. Mesmo grandes programas de OSS que muitas necessidade de configuração como o Apache não precisa de uma conexão com um banco de dados contendo uma tabela apache_config ao trabalho. Ter uma enorme quantidade de configuração para lidar com em seus aplicativos é um cheiro de código ruim, armazenando os dados em um banco de dados apenas causa mais problemas (como esta discussão ilustra).