Devem estes ser 3 tabelas SQL ou um?

Question

Esta é uma nova questão que surgiu a partir da esta questão

Devido às respostas, a natureza da questão mudou, então eu acho que a postar um novo é ok (?).

Você pode ver meu projeto DB original abaixo. Eu tenho 3 tabelas, e agora eu preciso de uma consulta para obter todos os registros para um usuário específico para cálculos running_balances.

• As transações são entre os usuários, como crédito mútuo. Assim unidades são trocadas entre os usuários.
• Inventarizations são coisas físicas trazidos para o sistema; um usuário recebe unidades para isso.
• Consumations são coisas físicas consumido; um utilizador tem de unidades de pagar por isso.

|--------------------------------------------------------------------------|
|  type     |  transactions       |  inventarizations  |  consumations     |
|--------------------------------------------------------------------------|
|  columns  |  date               |  date              |  date             |
|           |  creditor(FK user)  |  creditor(FK user) |                   |
|           |  debitor(FK user)   |                    |  debitor(FK user) |
|           |  service(FK service)|                    |                   |
|           |                     |  asset(FK asset)   |  asset(FK asset)  |
|           |  amount             |  amount            |  amount           |
|           |                     |                    |  price            |
|--------------------------------------------------------------------------|

. (Note que 'quantidade' está em unidades diferentes;. Estas são as entradas e cálculos são feitos sobre esses valores Fora do âmbito de explicar porquê, mas estes são os campos)

A pergunta é: "pode ??/ deve este estar em uma mesa ou ser várias tabelas (como eu tê-lo por agora)?" Eu gosto da solução de 3 mesas porque faz semanticamente mais sentido. Mas então eu preciso de uma declaração tão complicado select (com os resultados de desempenho possivelmente negativas) para os running_balances. A pergunta original no link acima pediu nesta declaração, aqui estou perguntando se o design db é apropriados (desculpas quatro dupla postagem, espero que seja ok).

Answer 1

Esta mesma pergunta surge quando você tentar implementar um sistema de contabilidade geral para a contabilidade de entrada única. O que você tem chamado de "transações" corresponde a "transferências", como da poupança para verificação. O que você tem chamado de "inventarizations" corresponde a "renda", como depositar um cheque de pagamento. O que você tem chamado corresponde "consumations" para "despesas", como quando você pagar a conta de energia elétrica. A única diferença é que, em contabilidade, tudo foi reduzido para dólar (ou outra moeda) valor. Então você não precisa se preocupar com ativos de identificação, porque um dólar é tão bom quanto outro.

Assim, a questão de saber se você precisa ter colunas separadas para "quantidade de débito" e "quantidade de crédito" ou, em alternativa, se você pode apenas ter uma coluna para "quantidade" e insira um número positivo para os débitos e um valor negativo para os créditos. Essencialmente a mesma pergunta surge se você estiver implementando contabilidade de dupla entrada, em vez de contabilidade de entrada única.

Em termos de aritmética interna e manipulação de dados interna, as coisas são muito mais simples quando você adota a abordagem única coluna. Por exemplo, para testar se uma determinada operação está em equilíbrio, tudo que você tem a fazer perguntar se sum (quantidade) é igual a zero.

As complicações surgem quando as pessoas exigem o formato bookeeping tradicional para formas de entrada de dados, por recuperações de tela e relatórios publicados. O formato tradicional exige duas colunas separadas, marcado "Débito" e "Crédito", que contêm apenas números positivos ou em branco, com a restrição de que cada item deve ter uma entrada em qualquer cartão de débito ou de crédito, mas não ambos, ea outra coluna deve ser deixado em branco. Estas transformações exigem uma certa quantidade de programação entre o formato externo e o formato interno.

É realmente uma questão de escolha. É melhor manter o formato de contabilidade tradicional de lado a coulmns débito lado e de crédito, ou é melhor para avançar para um formato que usa números negativos de uma maneira significativa? Existem algumas circunstâncias que favorecem cada uma dessas escolhas de design.

No seu caso, isso vai depender de como você pretende usar os dados. Eu iria construir protótipos com cada um dos dois projetos, em seguida, começar a trabalhar no processamento de CRUD fundamental para cada um. Qualquer um que obras fora mais fácil em seu ambiente é o único a escolher.

Answer 2

Você disse que essa quantia será diferentes unidades, então eu acho que você deve manter cada mesa para si.

Eu, pessoalmente, odeio um design DB que tem "regras diferentes" para o preenchimento de tabela com base no tipo de entidade que armazenado em uma fileira. Ele só fica confuso, e é difícil manter suas restrições vivo propperly sobre uma mesa assim.

Basta criar uma exibição indexada que irá responder às suas perguntas de equilíbrio para manter suas consultas "simples"

Answer 3

Não há uma resposta definitiva para isso e respostas será em grande parte para baixo para as metodologias de projeto de banco de dados adotados pelo respondente.

Meu conselho seria a julgamento em ambos os sentidos e ver qual delas tem o melhor compromisso entre a consulta, desempenho e manutenção / usabilidade.

Você pode sempre criar uma visão que retorna todos os 3 tabelas como uma tabela para consultar e tem um campo type para o tipo de processo de uma linha se refere a.