Como você lida com pequenos conjuntos de dados?

Question

Com muito pequenos conjuntos de dados, a política de onde eu trabalho é geralmente para colocá-los em arquivos de texto, mas na minha experiência, isso pode ser uma dor de cabeça de desenvolvimento. Os dados geralmente vem do banco de dados e quando isso não acontece, o processo envolvido na criação it / armazenamento é geralmente escondido no código. Com o banco de dados geralmente é possível ver todos os dados disponíveis para você e as maneiras com as quais se relaciona a outros dados.

Às vezes, por muito pequenos conjuntos de dados Eu apenas armazená-los em uma estrutura interna de dados no código (como um Perl de hash), mas, em seguida, quando é necessária uma mudança, é nas mãos de um desenvolvedor.

Então, como você lida com pequenos conjuntos de dados raramente mudaram? Você definiu critérios de quando usar uma tabela de banco de dados ou um arquivo de texto ou ..?

Estou tentado a usar uma tabela de banco de dados para absolutamente tudo, mas eu não tenho certeza se existem implicações para isso.

Editar: Para o contexto:

Já me pediram para colocar um novo formulário de contato no site para um punhado de empresas, com mais a ser adicionado ocasionalmente no futuro. Exceto, as empresas não têm endereços de contas de e-mail .. os usuários dentro essas empresas fazem (como eles postar empregos através de suas próprias contas). Agora, porém, queremos uma funcionalidade tipo "aplicação especulativa" e a forma precisa de um endereço de e-mail para enviar esses aplicativos para. Mas também não quer colocar um endereço de e-mail como uma propriedade no formulário ou então spammers pode simplesmente usá-lo como um gateway de e-mail aberta. Então, claramente, precisamos de um ID -> tipo de relacionamento contact_email com as empresas.

Então, eu pode adicionar uma coluna a uma tabela com milhões de linhas que serão utilizados, literalmente, cerca de 20 vezes ou criar uma nova tabela que, no máximo, vai realizar cerca de 20 linhas. Normalmente como lidamos com isso no passado é apenas para criar um arquivo de texto desagradável e lê-lo de lá. Mas isso cria pesadelos manutenção e esses arquivos de texto são frequentemente olhou quando os dados que dependem de mudanças. Talvez esta seja uma falha com o processo, mas eu estou apenas interessado em vistas de ouvir sobre isso.

Answer 1

Se estes são pequenos config-como de dados, eu uso algumas simples e formato comum. ini, JSON e yaml são geralmente ok. Java e .NET fãs também como XML. em suma, usar algo que você pode facilmente ler a um objeto na memória e esquecê-la.

Answer 2

Coloque-o no banco de dados. Se ele muda com freqüência, o cache-lo em sua camada intermediária.

Answer 3

O exemplo que vem à mente imediatamente é o que é apropriado ter armazenado como uma enumeração eo que é apropriado ter armazenado em uma "pesquisa" tabela de banco de dados.

I tendem a "traçar a linha" com a regra de que, se ele irá resultar em uma coluna no banco de dados que contém um "número mágico" que mapeia para um valor de enumeração, em seguida, a enumeração deve realmente existir como uma tabela de pesquisa. Se é não relacionado com os dados armazenados no banco de dados (por exemplo. De dados de configuração do aplicativo em vez de dados gerados por usuários), então é uma enumeração todo o caminho.

Answer 4

Com certeza, depende do usuário da ferramenta de software que você desenvolveu para consumir o conjunto de dados, independentemente do tamanho?

Pode ser apenas que eles sabem Excel, por isso, a sua ferramenta teria que analisar um arquivo .csv que eles criam.

Se ele é escrito para os desenvolvedores, então quem se importa o que você usa. Eu não sou um fã de desordenar bancos de dados com menor ou dados temporários no entanto.

Answer 5

Temos um formato padrão de arquivo de configuração (chave: valor) e uma classe para lidar com isso. Nós apenas usar isso em todos os projetos. Principalmente nós estamos apenas definindo as propriedades persistentes para nossas aplicações (desenvolvimento celular) Então, isso é uma coisa apropriada a fazer. YMMV

Answer 6

Nos casos em que o programa acessa um banco de dados, eu vou guardar tudo lá dentro:. Fácil para backup e movimentação de dados ao redor

Para os pequenos programas sem acesso ao banco eu armazenar meus dados nas configurações de .net, que são armazenados em um arquivo XML - é claro que isso é uma característica do c #, por isso pode não se aplicar a você

.

De qualquer forma, eu certifique-se de armazenar todos os dados em um único lugar. Normalmente, um banco de dados.

Answer 7

Você considerou sqlite ? Ele é baseado em arquivos, que aborda o seu sentimento de que "apenas um arquivo pode fazer" (configuração zero), mas é um perfeitamente bom banco de dados e escalas muito bem. Ele suporta um número de APIs e existem numerosas extremidades dianteiras para administrá-lo.

Answer 8

Gostaria de adicioná-lo ao banco de dados na tabela principal:

1. Backup e recuperação (você deseja recuperar esse arquivo de texto, certo?)
2. Adhoc consulta (desde que você pode fazê-lo será uma ferramenta SQL e juntá-lo para o outro de dados banco de dados)
3. Se a coluna de banco de dados é esvaziar os requisitos de armazenamento para ele deve ser mínima (nada se for uma coluna NULL no final da tabela no Oracle)
4. Será mais fácil se você quer ter vários servidores de aplicativos que você não terá que manter várias cópias de algum arquivo de configuração extra em torno
5. Colocá-lo em uma pequena mesa criança só complica o design sem dar quaisquer benefícios reais

Você pode muito bem já estar indo para a mesma linha no banco de dados como parte de seu processamento de qualquer maneira, por isso o desempenho não é provável que seja um problema. Se você não for, você pode armazená-lo na memória.