Qual banco de dados de código aberto é a melhor opção para um sistema relacionado à contabilidade?[fechado]

StackOverflow https://stackoverflow.com/questions/411976

Pergunta

Estou nos estágios iniciais de planejamento e criação de um aplicativo de contabilidade personalizado para minha empresa.Meu objetivo é utilizar um banco de dados relacional de código aberto para a parte de armazenamento de dados e estou ciente de dois bancos de dados sólidos que são amplamente suportados:MySQL e PostgreSQL.

Para um sistema que exigirá transações, procedimentos armazenados, funções e segurança, há alguma opinião sobre qual desses dois bancos de dados seria mais adequado para um aplicativo de contabilidade ou há outro banco de dados que estou faltando?

Estou mais familiarizado com MySQL e MS SQLServer 2005, mas estou tentando me afastar deste último devido aos custos de licença.

Deixe-me adicionar:Esta não é uma necessidade contábil como Quickbooks ou Peachtree.Este é basicamente um sistema que trata da contabilidade de um serviço comercial específico que prestamos.Existem talvez dois ou três sistemas que atendem a essa necessidade, têm preços na faixa de seis dígitos antes de qualquer personalização e exigiriam que minha pequena empresa se casasse com um fornecedor por um longo prazo.Portanto, estamos construindo o aplicativo internamente.

Além disso, embora eu aprecie o Comprar vs.Construir argumento, eu gostaria de me afastar dessa questão religiosa específica porque o caminho da compra já foi seguido e o vendedor falhou miseravelmente.Às vezes, você só precisa fazer o trabalho sozinho e este projeto e orçamento específicos garantem isso.

Obrigado pelas respostas de todos até agora.

Foi útil?

Solução

Existem quatro principais sistemas de gerenciamento de banco de dados relacional de código aberto que podem ser apropriados para esse tipo de aplicação:Postgresql, MySQL, Firebird e Ingres.Existem outros sistemas como SQLite, mas eles não possuem esse tipo de arquitetura e não são realmente projetados para esse tipo de carga de trabalho.Alguns outros sistemas de gerenciamento de banco de dados de código aberto desse tipo existem, mas não parecem ser fortemente viáveis ​​por algum motivo, como a aparente falta de comprometimento do fornecedor.Um exemplo de sistema que apresenta esse tipo de problema é SAP-DB.

Postgresql tem o melhor conjunto de recursos de qualquer banco de dados de código aberto e suporte para transações XA, que você provavelmente desejará se seu aplicativo for um sistema de três camadas e suportar transações de complexidade não trivial.Em particular, você desejará isso se quiser fazer transações abrangendo mais de uma chamada ao banco de dados.

Diversas variantes comerciais do PostgreSQL foram construídas ao longo dos anos, como Ilustração, Ameixa verde e EnterpriseDB. Illustra foi uma versão comercial do PostgreSQL que foi posteriormente comprada pela Informix.Greenplum é uma versão modificada projetada para aplicativos de armazenamento de dados.EnterpriseDB é uma empresa que fornece versões comerciais suportadas do PostgreSQL com alguns softwares de valor agregado.

MySQL 5.x possui um conjunto de recursos que suporta uma seção razoável de recursos, mas não é tão rico em recursos quanto o PostgreSQL.Ele tem uma aceitação mais ampla e seria o sistema de gerenciamento de banco de dados de código aberto mais fácil de recrutar desenvolvedores qualificados.Embora as versões mais antigas não tivessem suporte robusto a transações, mecanismos de armazenamento transacional como InnoDB já estão disponíveis há algum tempo.O atual política em torno da a aquisição pela Sun gerou garfos de código e o cenário do MySQL é um tanto bagunçado, com polêmica sobre problemas de qualidade na versão 5.1. No entanto, o MySQL é de longe o mais popular e conhecido dos sistemas de gerenciamento de banco de dados de código aberto e é o único com reconhecimento de marca significativo fora dos círculos de código aberto.

Pássaro de Fogo é uma versão de código aberto do Interbase.Da última vez que olhei, ele não tinha suporte a XA, mas seria bom se seu aplicativo fosse configurado como um sistema cliente-servidor de duas camadas. Atualizar: Não consigo encontrar uma especificação definitiva sobre isso, mas a documentação indica que ele tem suporte para commit em duas fases, mas o que consegui encontrar não foi específico sobre se ele suportava o protocolo XA.A documentação implica que o driver JDBC tem suporte para confirmações de duas fases.

Uma variante interessante deste sistema é Fogo, que foi projetado para oferecer um certo grau de compatibilidade com o Oracle.Este foi originalmente desenvolvido para uso como back-end para Compilar, que foi construído contra o Oracle e fortemente acoplado a ele.

Ingres agora está disponível com uma licença de código aberto, mas foi recebido com um bocejo coletivo pela comunidade de código aberto.No entanto, é bastante rico em recursos e muito maduro - conheço pessoas que faziam aplicativos INGRES em 1990, e isso remonta à década de 1980.

Outras dicas

Meu conselho? Não. Melhor comprar um. As pessoas que sabem mais sobre contabilidade escreveram bons pacotes que já lidam com o GAAP. Eles têm uma base de usuários maior do que você jamais terá, o que descobrirá defeitos mais rapidamente. Este é um clássico "Buy versus Build". Não há vantagem competitiva para a sua empresa escrevendo a sua. Se você está fazendo isso porque está preocupado com os custos de licença, diria que você não foi responsável pelo tempo de desenvolvimento corretamente. Essa é a única maneira de justificar fazer isso internamente.

Com isso dito, se você estiver preocupado com os custos de licenciamento do SQL Server, eu recomendaria o PostgreSQL primeiro ou o MySQL em segundo lugar como seu banco de dados de escolha.

Eu concordo fortemente com respostas de Duffymo e Tuinstoel e outros. Reconsidere sua decisão de construção versus compra. Deixe-me te contar uma historia:

Enquanto trabalhava em uma empresa de médio porte (International,> Receita de US $ 100 milhões/ano), o CFO decidiu substituir os sistemas financeiros pela Oracle Financials. Somente esse pacote não correspondia exatamente às práticas contábeis usadas por esta empresa.

Assim, o CFO contratou uma equipe de programadores de contratos e os pagou para personalizar as finanças da Oracle às práticas contábeis preferidas. Ela afundou 12 meses, US $ 1 milhão em salários de programador, além do custo inicial do software, apenas para duplicar o sistema contábil que eles pretendiam substituir.

Ela disse que se tivesse que fazer isso de novo, compraria o pacote comercial, mas adaptaria os hábitos contábeis da empresa aos padrões suportados pelo software. Isso seria muito mais fácil, mais rápido e mais provável de ter sucesso.

Portanto, considere o custo de criar seu próprio pacote personalizado. Considere também o custo contínuo da sua empresa de manutenção, depuração e aprimoramento para esse software. Mesmo se comprar um pacote comercial de seis dígitos, isso provavelmente será mais barato do que pagar aos programadores para desenvolver e manter esse sistema.

Para responder à sua pergunta declarada mais diretamente, não acho que haja uma diferença significativa entre o PostgreSQL e o MySQL que é relevante para o seu projeto. Como você se sente confortável com o MySQL, também pode acompanhar isso.

Eu gostaria de oferecer um lembrete obrigatório para não usar tipos de dados inexatos, como FLOAT ou DOUBLE PRECISION para dados financeiros.

Por algum Aplicativo que deseja usar um banco de dados de código aberto, a resposta sem receita é o Postgres. É muito mais "pronto para a empresa" do que o MySQL, sem mencionar que segue muito melhor o padrão SQL. O MySQL melhorou muito com suas versões posteriores, mas o Postgres ainda o supera em todas as categorias.

Existem sistemas de contabilidade livre de código aberto. Como osfinanciais. Eu realmente não consigo entender por que você quer construir seu próprio sistema?

Para o seu aplicativo, isso realmente não importa. Qualquer coisa, desde o SQLite a MySQL e Postgres provavelmente funcionaria muito bem. Escolha o que você mais familiariza.

Se você estiver familiarizado com o MySQL, use -o. Mas selecione o mecanismo de banco de dados adequado em vez do padrão myisam

Lista de motores de armazenamento

Honestamente, algum dos suspeitos usuais farão o trabalho. Manter o gráfico de contas e tabelas de dados relacionadas é o problema raiz que impulsionou quase todo o modelo relacional. De fato, se você pensar na visão geral do diário de um sistema contábil, tudo você tenho é o gráfico de contas e a revista geral, composta por número da transação, data, descrição, conta de débito e valor, conta de crédito e valor. Tudo o mais que você faz é uma seleção neles.

Dito isto, porém, existem tantas pacotes financeiros perfeitamente adequados, bem testados e aceitos, incluindo versões livres de código aberto (como em cerveja), que, a menos que você queira dizer isso para um etude, um projeto de estudo, eu colocaria meu esforço para pesquisar e selecionar um.

Vi sua atualização. O problema é que esse é um problema que será determinado principalmente por requisitos não funcionais. Você vai distribuir o banco de dados em mais de um servidor? Quanta carga você espera? Transações por segundo ou transações por dia? Eu construí sistemas em torno dos dois últimos anos, e geralmente são os requisitos de confiabilidade e avilabilidade que são os mais decisivos: o PostgreSQL lida com atualizações simultâneas de uma única linha com mais eficácia, aplicando atomicidade da linha e serializando atualizações simultâneas. Por outro lado, o MySQL parece lidar com bancos de dados realmente grandes. No entanto, uma terceira pergunta é o backup-um deles (não me lembro de qual agora) mais ou menos requer algum tempo de inatividade para fazer backup.

Para um aplicativo contábil interno baseado na Web, você pode estar melhor com o Gemstone como um banco de dados de objetos de código aberto, mas não de código aberto, como a estrutura da web. Também conhecido como vidro.

Para um aplicativo interno, você será limitado no esforço do desenvolvedor. A pedra preciosa, como uma imagem Smalltalk, fornece a melhor produtividade do desenvolvedor de longe. Seu suporte à migração de objetos ao alterar sua definição permite o desenvolvimento iterativo real. A Seaside substitui os modelos por uma linguagem bem projetada para criar aplicativos da Web.

eu construo Software de contabilidade no PostgreSQL. Funciona muito bem. Eu recomendo. De fato (plugue sem vergonha), você pode considerar trabalhar conosco para melhorar nosso projeto e usá -lo como um ponto de partida.

Existem algumas razões em particular:

  1. Ouvir/Notificar oferece a você a capacidade de conectar outros programas ao seu banco de dados contábil quando algo mudar sem precisar verificar as tabelas de vez em quando.
  2. Encontramos um desempenho extremamente bom com as consultas mais complexas.

Firebird e Ingres fornecerão uma solução relacional muito sólida. MySQL, eu não recomendaria porque você está realmente amarrando tudo a um aplicativo que pode escrever no banco de dados (o modo SQL Sope significa que as relações são basicamente uma API privada em vez da API pública em que estão no PostgreSQL, Firebird e Ingres), e Isso significa menos flexibilidade no futuro.

No entanto, com o PostgreSQL, você obtém uma plataforma de desenvolvimento extensível e de primeira linha em uma caixa. O ritmo de desenvolvimento é alto. É sólido de rocha. Os recursos avançados são muito útil. Você não ficará desapontado. Nós não fomos.

Se este for um aplicativo de desktop, você pode querer olhar para o sqlite. É muito conhecido, em domínio público, e não terrivelmente difícil de trabalhar.

Já que você não precisar Procedimentos armazenados, retire isso da sua lista.

Você ficará muito mais feliz para colocar a lógica de negócios em código, não no banco de dados. Se você tiver a chance de começar a "limpar", use o banco de dados para o que faz mais sentido - a persistência não o processamento.

Depois de tomar essa decisão, as diferenças sutis entre MySQL e PostgreSQL desaparecem. Ambos são motores relacionais que lidam com o SQL quase idêntico. Concentre -se nas coisas que eles fazem de melhor.

Recomendação: Torne seu aplicativo independente de qualquer peculiaridade do banco de dados.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top