Какая база данных с открытым исходным кодом является наилучшим вариантом для связанной с учетом системы? [закрытый]
Вы можете создать новую ветку с историей главной ветви удаленного:
$ git fetch
$ git checkout -b master2 origin/master
# now if 'master2' branch is ok, then replace 'master' with 'master2'
$ git branch -D master # delete the local master branch
# create & checkout to a new local 'master' branch = master2 = origin/master
$ git checkout -b master
Теперь ветка master2 должна иметь ту же историю с origin/master
ИЛИ , вы можете reset ваш локальный мастер с историей удаленного / мастер
$ git checkout master
$ git branch master.bac # backup just for safety
$ git fetch
$ git reset --hard origin/master
РЕДАКТИРОВАТЬ:
Я получил проблему наблюдения ваше репо , что ваша локальная master ветка не обновлена. Просто обновите локального мастера:
$ git checkout master
$ git pull origin master
N.B. предыдущие решения также должны работать.
12 ответов
Существует четыре основных знаменитых системы управления реляционными базами данных с открытым исходным кодом, которые могли бы соответствовать этому виду приложения: Postgresql, MySQL, Firebird и Ingres. Существуют другие системы, такие как SQLite, но они не имеют этого типа архитектуры и действительно не разработаны для этого типа рабочей нагрузки. Некоторые другие системы управления базами данных с открытым исходным кодом этого типа существуют, но, кажется, не решительно жизнеспособны по некоторым причинам, не таковы как отсутствие очевидного обязательства поставщика. Примером системы, которая имеет этот тип проблемы, является SAP-DB.
Postgresql имеет лучший набор функций любой из баз данных с открытым исходным кодом и поддержку транзакций XA, которые Вы, вероятно, захотите, если Ваше приложение будет трехуровневой системой и будет поддерживать транзакции нетривиальной сложности. В особенности Вы захотите это, если Вы захотите сделать транзакции, охватывающие больше чем один вызов к базе данных.
Несколько коммерческих вариантов PostgreSQL были созданы за эти годы, такие как Illustra, Greenplum и EnterpriseDB. Illustra был коммерческой версией PostgreSQL, который был впоследствии куплен Informix. Greenplum является mofified версией, разработанной для приложений организации хранилищ данных. EnterpriseDB является компанией, которая предоставляет поддерживаемым коммерческим версиям PostgreSQL с некоторым программным обеспечением с добавленной стоимостью.
MySQL 5.x имеет набор функций, который поддерживает разумное сечение возможностей, но это не столь многофункционально как PostgreSQL. Это имеет более широко распространенное основное принятие и было бы самым легким из систем управления базами данных с открытым исходным кодом принять на работу квалифицированных разработчиков на. Хотя более старые версии не имели устойчивой поддержки транзакции, механизмы системы хранения транзакций, такие как InnoDB были доступны в течение некоторого времени. текущий политика окружение приобретение Sun генерировало ветвления кода и среду MySQL, несколько грязен с противоречием о проблемах качества в этих 5,1 выпусках. Однако MySQL является безусловно самым популярным и самым известным из систем управления базами данных с открытым исходным кодом и является единственным со значительной узнаваемостью бренда за пределами кругов с открытым исходным кодом.
Firebird является версией с открытым исходным кодом Межосновы. В последний раз я смотрел, это не имело поддержки XA, но будет прекрасно, если Ваше приложение было настроено как двухуровневая система клиент-сервер. Обновление: Я не могу найти категорическую спецификацию на этом, но документация действительно указывает, что имеет поддержку двухфазной фиксации, но что я мог найти, не было конкретно по поводу того, поддерживала ли она протокол XA. Документация подразумевает, что драйвер JDBC действительно имеет поддержку двухфазных фиксаций.
Интересным вариантом в этой системе является Fyracle, который разработан для предложения степени совместимости с Oracle. Это было первоначально разработано для использования в качестве бэкенда к Compiere, который был создан против Oracle и вполне сильно связан к ней.
Ingres теперь доступен с лицензией с открытым исходным кодом, но был встречен чем-то вроде коллективного зевка сообществом разработчиков ПО с открытым исходным кодом. Однако Это является довольно многофункциональным и очень сформировавшимся - я знаю людей, которые делали приложения INGRES в 1990, и это относится ко времени 1980-х.
Мой совет? Не делать. Лучше купить тот. Люди, которые знают больше об учете, записали хорошие пакеты, которые уже имеют дело с GAAP. У них есть большая база пользователей, чем Вы будете когда-либо иметь, который раскроет дефекты быстрее. Это - классик, "покупают по сравнению со сборкой". Нет никакого конкурентного преимущества к Вашей фирме путем записи их собственного. Если Вы делаете его, потому что Вы волнуетесь по поводу стоимости лицензии, я сказал бы, что Вы не считали в течение времени разработки правильно. Это - единственный способ, которым Вы могли выровнять по ширине выполнение этого внутреннего.
После этих слов если бы Вы волнуетесь по поводу затрат на лицензирование SQL Server, я рекомендовал бы PostgreSQL сначала или MySQL, второй как Ваша предпочтительная база данных.
Я соглашаюсь сильно с ответами от duffymo и tuinstoel и других. Пересмотрите свою сборку по сравнению с решением покупки. Позвольте мне рассказать Вам историю:
В то время как я работал в средней компании (международный>, $100 миллионов / Ваш доход), финансовый директор решил заменить финансовые системы Финансовыми документами Oracle. Только тот пакет точно не соответствовал практике отчетности, используемой этой компанией.
Таким образом, финансовый директор нанял команду программистов контракта и заплатил им для настройки Финансовых документов Oracle к предпочтительной практике отчетности. Она сниженный 12 месяцев времени, $1 миллион в заработной плате программиста, плюс начальная стоимость программного обеспечения, только для дублирования системы учета, которую они намеревались заменить.
Она сказала, должна ли она была переделать его снова, она купила бы коммерческий пакет, но адаптировала бы бухгалтерские привычки компании к значениям по умолчанию, поддерживаемым программным обеспечением. Это было бы намного легче, более быстрым, и более вероятно успешно выполняться.
Поэтому рассмотрите стоимость создания Вашего собственного пакета. Также рассмотрите продолжающуюся стоимость для своей компании по обслуживанию, отладке и улучшению для того программного обеспечения. Даже если купят коммерческий пакет с шестью числами, то это, вероятно, будет менее дорогим, чем оплата услуг программистам, чтобы разработать и обслужить такую систему.
Для ответа на установленный вопрос более непосредственно я не думаю, что существует значительная разница между PostgreSQL и MySQL, который относится к проекту. Так как Вы довольны MySQL, Вы могли бы также пойти с этим.
Я хотел бы предложить обязательное напоминание для не использования неточных типов данных как FLOAT или DOUBLE PRECISION для финансовых данных.
Существуют свободные системы учета с открытым исходным кодом. Как osFinancials. Я действительно не могу понять, почему Вы хотите создать свою собственную систему?
Для любого приложения, которое хочет использовать базу данных с открытым исходным кодом, ответом рук вниз является Пост-ГРЭС. Это НАМНОГО более "готово к предприятию", чем MySQL, не говоря уже о том, что это следует стандарту SQL намного лучше. MySQL улучшился много с его более поздними версиями, но Пост-ГРЭС все еще побеждает его в каждой категории.
Для Вашего приложения это не будет действительно иметь значения. Что-либо от sqlite до MySQL к Пост-ГРЭС, вероятно, работало бы просто великолепно. Выберите тот, с которым Вы являетесь самыми знакомыми.
Если Вы знакомы с MySQL, затем используют его. Но выберите надлежащий механизм базы данных вместо MyISAM по умолчанию
Для внутреннего веб-приложения учета Вы могли бы быть более обеспечены с Драгоценным камнем как свободное, но не объектная база данных с открытым исходным кодом и Побережье как веб-платформа. Иначе известный как СТЕКЛО.
Для внутреннего приложения Вы собираетесь быть ограниченными в усилии разработчика. Драгоценный камень, как изображение smalltalk, обеспечивает лучшую производительность разработчика безусловно. Его поддержка миграции объектов при изменении их определения позволяет реальную итерационную разработку. Побережье заменяет шаблоны хорошо разработанным проблемно-ориентированным языком для создания веб-приложений.
Честно, любой из обычных подозреваемых сделает задание. Поддержание плана счетов и связанных таблиц данных является основной проблемой, которая управляла большинством всей реляционной моделью. На самом деле, если Вы думаете о представлении журнала операций системы учета, все, что Вы имеете, план счетов и журнал операций, состоявший из числа транзакции, даты, описания, дебетовой учетной записи и суммы, кредитового счета и суммы. Все остальное, что Вы делаете, является ВЫБОРОМ на тех.
Тем не менее, хотя, существует столько совершенно соответствующих, хорошо протестированных и принятых пакетов финансовых программ, включая бесплатный открытый исходный код (как в пиве) версии, что, если Вы не имеете в виду это для этюда, проекта исследования, я приложил свои усилия к поиску с помощью Google и выбору того.
Видел Ваше обновление. Вещь, это - проблема, это главным образом будет решительным нефункциональными требованиями. Вы собираетесь распределить базу данных больше чем через один сервер? сколько загрузки Вы ожидаете? Транзакции в секунду или транзакции в день? Я создал системы и вокруг в последних годах, и это обычно - надежность и avilability требования, которые являются самыми решающими: PostgreSQL имеет дело с параллельными обновлениями одной строки эффективнее путем осуществления атомарности строки и сериализации параллельных обновлений. С другой стороны, MySQL, кажется, имеет дело с действительно большими базами данных лучше. Все же третьим вопросом является резервное копирование---один из них (я не вспоминаю, какой прямо сейчас), более или менее требует, чтобы некоторое время простоя скопировало.
Так как Вам не нужны хранимые процедуры, возьмите это от своего списка.
Вы будете намного более счастливой бизнес-логикой помещения в коде, не в базе данных. Если у Вас есть шанс запуститься "чистый", то используйте базу данных для того, что имеет большую часть смысла - персистентность, не обрабатывающая.
После того как Вы принимаете то решение, тонкие различия между MySQL и PostgreSQL уходят. Оба - реляционные механизмы, которые обрабатывают почти идентичный SQL. Внимание на вещи они прилагают все усилия.
Рекомендация: Сделайте свои не зависящие от приложения из любых особенностей базы данных.
Если это - настольное приложение, Вы могли бы хотеть посмотреть на SQLite. Это очень хорошо известно в общественном достоянии, и не ужасно трудное работать с.