Какая база данных с открытым исходным кодом является наилучшим вариантом для системы учета?

Ответ 1

Существует четыре основные системы управления реляционными базами данных с открытым исходным кодом, которые могут быть подходящими для такого типа приложений: Postgresql, MySQL, Firebird и Ingres. Существуют и другие системы, такие как SQLite,, но они не имеют такого типа архитектуры и на самом деле не предназначены для такого типа рабочей нагрузки. Некоторые другие системы управления базами данных с открытым исходным кодом такого типа существуют, но по какой-то причине они кажутся нежизнеспособными, например, отсутствие явных обязательств поставщиков. Примером системы, которая имеет этот тип проблемы, является SAP-DB.

Postgresql имеет лучший набор функций любой из баз данных с открытым исходным кодом и поддержку транзакций XA, которые вы, вероятно, захотите если ваше приложение представляет собой трехуровневую систему и поддерживает транзакции нетривиальной сложности. В частности, вам понадобится это, если вы хотите совершать транзакции, охватывающие более одного вызова базы данных.

Несколько коммерческих вариантов PostgreSQL были построены на протяжении многих лет, например Illustra, Greenplum и EnterpriseDB. Illustra был коммерческим выпуском PostgreSQL, который впоследствии был куплен Informix. Greenplum - это модифицированная версия, предназначенная для приложений хранения данных. EnterpriseDB - это компания, которая предоставляет поддерживаемые коммерческие версии PostgreSQL с помощью программного обеспечения с добавленной стоимостью.

MySQL 5.x имеет набор функций, который поддерживает разумное поперечное сечение возможностей, но он не настолько функциональный, как PostgreSQL. Он имеет более широкое признание и является самой простой из систем управления базами данных с открытым исходным кодом для привлечения квалифицированных разработчиков. Хотя более старые версии не имели надежной поддержки транзакций, в течение некоторого времени были доступны механизмы транзакционного хранения, такие как InnoDB. текущий политика окружающий, приобретение Sun привело к созданию кодовых вилок, а ландшафт MySQL - несколько грязный, с разногласиями о проблемах с качеством в версии 5.1. Однако MySQL самая популярная и известная из систем управления базами данных с открытым исходным кодом и является единственной, обладающей значительным признанием бренда за пределами открытых источников.

Firebird - это версия Interbase с открытым исходным кодом. Последнее, что я посмотрел, у него не было поддержки XA, но было бы хорошо, если бы ваше приложение было настроено как двухуровневая система клиент-сервер. Обновление: Я не могу найти окончательную спецификацию по этому вопросу, но документация показывает, что она поддерживает двухфазную фиксацию, но то, что я мог найти, не было конкретным в том, поддерживает ли он протокол XA, Документация подразумевает, что драйвер JDBC имеет поддержку двухфазных коммитов.

Интересным вариантом этой системы является Fyracle, который призван обеспечить степень совместимости с Oracle. Первоначально он был разработан для использования в качестве back-end для Compiere, который был построен против Oracle и довольно тесно связан с ним.

Ingres теперь доступен с лицензией с открытым исходным кодом, но был встречен с небольшим количеством коллективного зевания, источник сообщества. Однако он довольно многофункциональный и очень зрелый - я знаю людей, которые делали приложения INGRES в 1990 году, и это относится к 1980-м годам.

Ответ 2

Мой совет? Не. Лучше купить его. Люди, которые знают больше о бухгалтерском учете, написали хорошие пакеты, которые уже имеют дело с GAAP. У них большая пользовательская база, чем у вас когда-либо, что быстрее выявит дефекты. Это классическая "покупка против сборки". Там нет конкурентного преимущества для вашей фирмы, написав свои собственные. Если вы это делаете, потому что беспокоитесь о стоимости лицензии, я бы сказал, что вы не учли время разработки должным образом. Это единственный способ, которым вы могли бы оправдать это внутри.

С учетом сказанного, если вы обеспокоены расходами на лицензирование SQL Server, я бы рекомендовал сначала PostgreSQL или MySQL второй в качестве вашей базы данных по выбору.

Ответ 3

Я полностью согласен с ответами от duffymo и tuinstoel и других. Пересмотрите решение о покупке или покупке. Позвольте мне рассказать вам историю:

В то время как я работал в компании среднего размера (международный доход в $100 млн./год), финансовый директор решил заменить финансовые системы Oracle Financials. Только этот пакет точно не соответствовал методам бухгалтерского учета, используемым этой компанией.

Таким образом, финансовый директор нанял команду контрактных программистов и заплатил им, чтобы настроить Oracle Financials на предпочтительные методы бухгалтерского учета. Она затонула через 12 месяцев, 1 миллион долларов в зарплате программиста, плюс первоначальная стоимость программного обеспечения, просто чтобы дублировать систему учета, которую они намеревались заменить.

Она сказала, что если ей придется это сделать снова, она купит коммерческий пакет, но приспособит привычки учета компании к значениям по умолчанию, поддерживаемым программным обеспечением. Это будет намного проще, быстрее и с большей вероятностью преуспеть.

Поэтому рассмотрим стоимость создания собственного пакета. Также рассмотрите текущую стоимость вашей компании по обслуживанию, отладке и расширению для этого программного обеспечения. Даже если купить шестизначный коммерческий пакет, это, вероятно, будет дешевле, чем платить программистам за разработку и обслуживание такой системы.

Чтобы ответить на ваш заявленный вопрос более прямо, я не думаю, что существует значительная разница между PostgreSQL и MySQL, которая имеет отношение к вашему проекту. Так как вам удобно с MySQL, вы также можете пойти с этим.

Я хотел бы предложить обязательное напоминание о том, чтобы не использовать неточные данные, такие как FLOAT или DOUBLE PRECISION для финансовых данных.

Ответ 4

Для любого приложения, которое хочет использовать базу данных с открытым исходным кодом, раздаточный ответ - Postgres. Это намного более "готовый к работе", чем MySQL, не говоря уже о том, что он намного лучше соответствует стандарту SQL. MySQL значительно улучшил свои версии, но Postgres по-прежнему превосходит его в каждой категории.

Ответ 5

Существуют системы бесплатного учета с открытым исходным кодом. Как osFinancials. Я действительно не понимаю, почему вы хотите создать свою собственную систему?

Ответ 6

Для вашего приложения это не имеет большого значения. Все, что от sqlite до MySQL до Postgres, вероятно, будет работать нормально. Выберите тот, с которым вы больше всего знакомы.

Ответ 7

Firebird - http://www.firebirdsql.org/

Ответ 8

Если вы знакомы с MySQL, используйте его. Но выберите правильный механизм базы данных вместо стандартного MyISAM

Список устройств хранения

Ответ 9

Честно говоря, любой из обычных подозреваемых будет выполнять эту работу. Поддержание схемы счетов и связанных таблиц данных является основной проблемой, которая приводит большинство реляционных моделей. Фактически, если вы думаете об общем виде журнала системы учета, все, что у вас есть, это диаграмма счетов и общий журнал, состоящий из номера транзакции, даты, описания, дебетовой учетной записи и суммы, кредитной учетной записи и суммы. Все остальное, что вы делаете, это SELECT на них.

Тем не менее, существует так много вполне адекватных, проверенных и принятых финансовых пакетов, включая версии с открытым исходным кодом (как в пивных), если вы не имеете в виду это для этюда, учебный проект, Я бы приложил все усилия к поиску в Интернете и выбору одного из них.

Увидите свое обновление. Дело в том, что это проблема, которая в основном будет определяться нефункциональными требованиями. Собираетесь ли вы распространять базу данных на нескольких серверах? сколько нагрузки вы ожидаете? Сделки в секунду или транзакции в день? Я создал системы вокруг обоих в последние пару лет, и это, как правило, требования к надежности и способности к avilability, которые являются наиболее решающими: PostgreSQL имеет дело с одновременными обновлениями одной строки более эффективно, заставляя атомизировать строки и сериализовать параллельные обновления. С другой стороны, MySQL, похоже, лучше справляется с действительно большими базами данных. Тем не менее, третий вопрос заключается в резервном копировании: один из них (я не помню, какой именно сейчас) более или менее требует некоторого времени простоя для резервного копирования.

Ответ 10

Для внутреннего веб-приложения учета вам может быть лучше с Gemstone в качестве бесплатной, но не открытой исходной базы данных объектов и Seaside в качестве веб-структуры. В противном случае он известен как GLASS.

Для внутреннего приложения вы будете ограничены в усилиях разработчиков. Gemstone, как небольшое изображение, обеспечивает лучшую производительность разработчика на сегодняшний день. Его поддержка миграции объектов при изменении их определения позволяет итеративное развитие. Seaside заменяет шаблоны хорошо продуманным доменным языком для создания веб-приложений.

Ответ 11

Я построю бухгалтерское программное обеспечение на PostgreSQL. Он работает очень хорошо. Я бы очень рекомендовал его. Фактически (бесстыдный плагин), вы можете подумать о том, чтобы работать с нами, чтобы улучшить наш проект и использовать его в качестве точки перехода.

В частности, есть несколько причин:

• LISTEN/NOTIFY дает вам возможность подключать другие программы к вашей учетной записи db, когда что-то меняется, не проверяя таблицы так часто.
• Мы обнаружили чрезвычайно хорошую производительность при работе с наиболее сложными запросами.

Firebird и Ingres предоставят вам очень надежное реляционное решение. MySQL я бы не рекомендовал, потому что вы действительно привязываете все только к одному приложению, которое может писать в db (суп-режим sql означает, что отношения в основном представляют собой частный API, а не публичный API, который они находятся в PostgreSQL, Firebird и Ingres), и это означает меньшую гибкость по дороге.

Однако с PostgreSQL вы получаете первоклассную расширяемую платформу разработки в коробке. Темп развития высок. Это твердый камень. Расширенные функции очень полезны. Вы не будете разочарованы. Мы не были.

Ответ 12

Если это настольное приложение, вы можете посмотреть на SQLite. Это очень хорошо известно, в общественном достоянии, и не очень сложно работать.

Ответ 13

Поскольку вы не используете требуемые хранимые процедуры, отмените это из своего списка.

Вы будете намного счастливее ставить бизнес-логику в код, а не в базу данных. Если у вас есть шанс начать "очистить", то используйте базу данных, для чего наиболее ощутимо - упорство не обрабатывается.

Как только вы примете это решение, тонкие различия между MySQL и PostgreSQL исчезнут. Оба являются реляционными двигателями, которые обрабатывают почти идентичный SQL. Сосредоточьтесь на том, что они делают лучше всего.

Рекомендация. Сделайте ваше приложение независимым от каких-либо особенностей базы данных.