Какая база данных с открытым исходным кодом является лучшим вариантом для системы, связанной с бухгалтерским учетом? [закрыто]
https://stackoverflow.com/questions/411976
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я нахожусь на ранних стадиях планирования и разработки индивидуального бухгалтерского приложения для моей фирмы. Моя цель - использовать реляционную базу данных с открытым исходным кодом для хранения данных, и мне известны две надежные базы данных, которые широко поддерживаются: MySQL и PostgreSQL.
Для системы, которая потребует транзакций, хранимых процедур, функций и безопасности, есть ли мнения о том, какая из этих двух баз данных лучше всего подойдет для приложения бухгалтерского учета, или мне не хватает другой базы данных?
Я более знаком с MySQL и MS SQLServer 2005, но я пытаюсь отойти от последнего из-за стоимости лицензии.
Позвольте мне добавить: это не такая бухгалтерская необходимость, как Quickbooks или Peachtree. Это в основном система, которая обрабатывает учет конкретных бизнес-услуг, которые мы предоставляем. Возможно, есть две или три системы, которые удовлетворяют эту потребность, оцениваются в шестизначном диапазоне перед любой настройкой и требуют, чтобы моя небольшая фирма была замужем за поставщиком на длительный срок. Таким образом, мы создаем приложение самостоятельно.
Кроме того, хотя я ценю аргумент Buy vs. Build , я бы хотел отойти от этого конкретного религиозного вопроса, потому что дорога Buy уже была выбрана, а продавец потерпел неудачу. Иногда вам просто нужно сделать работу самостоятельно, и этот конкретный проект и бюджет это оправдывают.
Спасибо за все ответы до сих пор.
Решение
Существует четыре основные системы управления реляционными базами данных с открытым исходным кодом, которые могут подойти для такого рода приложений: 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 поддерживает двухфазные коммиты.
Другие советы
Мой совет? Не. Лучше купить один. Люди, которые знают больше о бухгалтерском учете, написали хорошие пакеты, которые уже имеют дело с GAAP. Они имеют большую пользовательскую базу, чем вы когда-либо, что позволит быстрее обнаруживать дефекты. Это классическая «покупка против сборки». Там нет конкурентного преимущества для вашей фирмы, написав свои собственные. Если вы делаете это, потому что беспокоитесь о стоимости лицензии, я бы сказал, что вы не учли время разработки должным образом. Это единственный способ оправдать это собственными силами.
С учетом вышесказанного, если вас беспокоит стоимость лицензирования SQL Server, я бы рекомендовал сначала PostgreSQL или MySQL в качестве предпочтительной базы данных.
Я полностью согласен с ответами от duffymo, tuinstoel и других. Пересмотрите решение о сборке и покупке. Позвольте мне рассказать вам историю:
Пока я работал в компании среднего размера (международный, доход > 100 млн. долл. США в год), финансовый директор решил заменить финансовые системы Oracle Financials. Только этот пакет не совсем соответствовал методам бухгалтерского учета, используемым этой компанией.
Таким образом, финансовый директор нанял команду программистов-контрактников и заплатил им за то, чтобы настроить Oracle Financials в соответствии с предпочтительными методами учета. Она потратила 12 месяцев времени на заработную плату программиста в 1 миллион долларов плюс начальную стоимость программного обеспечения, просто чтобы дублировать систему бухгалтерского учета, которую они намеревались заменить.
Она сказала, что если ей придется сделать это снова, она купит коммерческий пакет, но адаптирует бухгалтерские привычки компании к настройкам по умолчанию, поддерживаемым программным обеспечением. Это было бы намного проще, быстрее и с большей вероятностью.
Так что подумайте о стоимости создания собственного пакета. Также рассмотрите текущую стоимость вашей компании по обслуживанию, отладке и усовершенствованию этого программного обеспечения. Даже если купить коммерческий пакет из шести цифр, это, вероятно, будет дешевле, чем платить программистам за разработку и обслуживание такой системы.
<Ч>Чтобы ответить на заданный вами вопрос более прямо, я не думаю, что есть существенная разница между PostgreSQL и MySQL, которая имеет отношение к вашему проекту. Так как MySQL вас устраивает, вы можете с этим согласиться.
Я хотел бы предложить обязательное напоминание не использовать неточные типы данных, такие как FLOAT или DOUBLE PRECISION для финансовых данных.
Для любого приложения, которое хочет использовать базу данных с открытым исходным кодом, практический ответ - Postgres. Это ОЧЕНЬ более "готово к предпринимательству" чем MySQL, не говоря уже о том, что он намного лучше следует стандарту SQL. MySQL значительно улучшился с более поздними версиями, но Postgres по-прежнему превосходит его в каждой категории.
Существуют бесплатные системы учета с открытым исходным кодом. Как и osFinancials. Я действительно не могу понять, почему вы хотите построить свою собственную систему?
Для вашего приложения это не имеет большого значения. Все, от sqlite до MySQL и Postgres, вероятно, будет работать нормально. Выберите тот, который вам наиболее знаком.
Firebird - http://www.firebirdsql.org/
Если вы знакомы с MySQL, используйте его. Но выберите правильный движок базы данных вместо MyISAM по умолчанию
Честно говоря, любой из обычных подозреваемых сделает эту работу. Поддержание плана счетов и связанных таблиц данных является основной проблемой, которая привела в движение большую часть всей реляционной модели. На самом деле, если вы думаете об общем представлении журнала системы учета, все, что у вас есть , - это план счетов и общий журнал, состоящий из номера транзакции, даты, описания, дебетового счета и сумма, кредитный счет и сумма. Все остальное, что вы делаете, это ВЫБРАТЬ на них.
Тем не менее, существует так много совершенно адекватных, хорошо протестированных и принятых финансовых пакетов, включая бесплатные версии с открытым исходным кодом (как в пиве), что если вы не имеете в виду это для этюда, учебного проекта Я бы приложил усилия к поиску и поиску одного.
Увидел ваше обновление. Дело в том, что это проблема, которая в основном будет определяться нефункциональными требованиями. Собираетесь ли вы распределить базу данных по нескольким серверам? какую нагрузку вы ожидаете? Транзакций в секунду или транзакций в день? В последние пару лет я создавал системы для обеих систем, и обычно решающими являются требования к надежности и доступности: PostgreSQL более эффективно справляется с одновременным обновлением одной строки, обеспечивая атомарность строк и сериализацию параллельных обновлений. С другой стороны, MySQL лучше справляется с действительно большими базами данных. И все же третий вопрос - резервное копирование - один из них (я не помню, какой именно сейчас) более или менее требует некоторого времени простоя для резервного копирования.
Для внутреннего бухгалтерского веб-приложения вам может быть лучше использовать Gemstone в качестве бесплатной, но не с открытым исходным кодом объектной базы данных и Seaside в качестве веб-инфраструктуры. В противном случае известен как СТЕКЛО.
Для внутреннего приложения вы будете ограничены в усилиях разработчика. Gemstone, как образ малого разговора, обеспечивает лучшую производительность разработчиков. Его поддержка переноса объектов при изменении их определения обеспечивает реальную итеративную разработку. Seaside заменяет шаблоны хорошо разработанным доменным языком для создания веб-приложений.
Я строю бухгалтерское программное обеспечение на PostgreSQL. Это работает очень хорошо. Я очень рекомендую это. На самом деле (бесстыдный плагин) вы можете поработать с нами над улучшением нашего проекта и использовать его в качестве отправной точки.
В частности, есть несколько причин:
<Ол>Firebird и Ingres предоставят вам очень надежное реляционное решение. MySQL я бы не советовал, потому что вы действительно привязываете все к одному приложению, которое может записывать в db (супплей режима sql означает, что отношения - это в основном закрытый API, а не публичный API в PostgreSQL, Firebird и Ingres), и это означает меньшую гибкость в будущем.
Тем не менее, с PostgreSQL вы получаете первоклассную расширяемую платформу разработки в коробке. Темпы развития высоки. Это твердое тело. Расширенные функции очень полезны. Вы не будете разочарованы. Мы не были.
Если это настольное приложение, вы можете посмотреть на SQLite. Это очень хорошо известно, в свободном доступе, и с ним не очень сложно работать.
Поскольку вам не нужны хранимые процедуры, удалите их из своего списка.
Вы будете намного счастливее помещать бизнес-логику в код, а не в базу данных. Если у вас есть возможность запустить «очистить», то используйте базу данных для того, что имеет смысл - постоянство, а не обработка.
Как только вы примете это решение, тонкие различия между MySQL и PostgreSQL исчезнут. Оба являются реляционными механизмами, которые обрабатывают почти идентичный SQL. Сосредоточьтесь на том, что они делают лучше всего.
Рекомендация . Сделайте свое приложение независимым от каких-либо особенностей базы данных.
