База данных для маленькой программы продаж/склада

[vitaly_l]

Лучший вариант Firebird, она без изменений работает и встроенно и сервером, да и по возможностям ближе к бухгалтерскому софту

Она делает автоматическую синхронизацию с сервером?


.

[azsx]

Лучший вариант Firebird, она без изменений работает и встроенно и сервером, да и по возможностям ближе к бухгалтерскому софту

а чем она лучше MySQL?

[Ism]

Она делает автоматическую синхронизацию с сервером?

Зачем это складской программе ? А при желании есть софт

а чем она лучше MySQL?

У Mysql встроенный клиент платный
В Firebird нет ничего лишнего, типа движков myisam и прочего
В Firebird есть роли

[wavebvg]

а чем она лучше MySQL?

Да ничем она не лучше.

Вообще, если Вы пишете толстый клиент, тогда лучше всего тщательно предусмотреть, чтобы все вопросы решались простыми SQL запросами, чтобы смена СУБД была лишь вопросом изменения нескольких строк конфигурации и минимального тестирования.

Если же Вы собираетесь писать лишь программу для отображения и управления, а логику всю разместить в базе данных, то тут придется сразу решить, что для вас лучше. С практической точки зрения, MySQL проще, потому что Вы сможете быстро развернуть простую инфраструктуру на любом хостинге для сайтов, но будьте готовы, что помимо удивительной производительности при 10-100 млн. записей Вас будет ждать невиданные сюрпризы с деадлоками (InnoDB) там, где их быть не должно (никаких запросов к той же таблице при обновлении и т.п.).
С другой стороны, Firebird позволяет избежать многих проблем (особенно при написании триггеров и т.п.), но с простым развертыванием будут некоторые проблемы - тут нужна явная поддержка Firebird. Да и с масштабированием при 1 млн. и выше могут возникнуть некоторые проблемы, особенно при холодном старте.

[azsx]

В Firebird есть роли

роли MySQL слабее ролей Firebird или разница ваще капитальная? Просто в мускуле также роли есть.

У Mysql встроенный клиент платный

серьезно???
---
про движки и прочего. Мускул круче этим для меня, но тс видней, я ваще за самое простое решение

[vitaly_l]

Зачем это складской программе ?

Ну вообще-то складской программе это нужно в первую очередь, т.к. нужно постоянно синхронизировать данные локальной базы с магазином, который на сервере. ( но это моё мнение, оно может различаться с мнением топик-стартера ). Наверняка у него на сервере магазин сделан на MySQL, если это так, то топик-стартеру, даже рекомендуется MySQL, т.к. он иначе запутается в базах.


.

[azsx]

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

пусть как все сливает по крону цсв файлами. Без глупостей
зы
рискну погадать, что синхронизация - это нечто иное. Ну в моих определениях.

[resident]

Значит мне нужно остановить свой выбор либо на MySQL либо на MariaDB. Но что выбрать непонятно.

У меня похожая ситуация. Опишу мои поиски новичка, может в чем и ошибаюсь.
Выбрал Postrges.
Причем MySQL тоже задействован, но это вынужденная мера, потому как PrestaShop.

з.ы.
В пользу Postgres еще (ну мало ли на будущее):
1) Вроде как основа для импортозамещения
2) Возможность работы вместе с 1С
3) Шикарная документация
4) Единственная база с исконным диалектом SQL

Можете ознакомится
https://www.youtube.com/channel/UCawnwM ... 69A/videos

Из минусов MySQL
1) Чехарда с версиями. Каждая новая версия будет ломать об колено ваш код, в Лазарусе шесть компонентов в зависимости от версии!
2) Не понравилась документация

Серьезных варианта всего два или Postgres или Firebird.
Postgres сейчас везде и развивается, на любой вопрос найдете ответ или подскажут.
Тысяча публикаций на хабре
https://habrahabr.ru/search/?q=Postgresql
Firebird какой-то полудохлый (да простят меня фанаты, но именно такое впечатление после беглого ознакомления). Хотя отрицательных отзывов не видел. Также подходит для импортозамещения и 1С.
На хабре 92 публикации
https://habrahabr.ru/search/?q=Firebird

[azsx]

Мне лично в Postrges не понравилось, что родные таблеспайсы при обновлении с 9,3 до 9,5 толком не перенеслись. В итоге оказалось проще удалить старую версию и восстановить новую с архива. Также в Postrges мне крайне не нравится как он относится к кодировкам. Не понимаю я его отношения. зы мелочь, но Postrges на винде работает значительно хуже, по сравнению с никс - по мнению разработчиков.

Firebird какой-то полудохлый (да простят меня фанаты, но именно такое впечатление после беглого ознакомления). Хотя отрицательных отзывов не видел.

на Firebird какой то дальней версии я столкнулся, что когда винт забивается до упора, Firebird начинает просто затирать старые записи и писать новые. К тому же я не заметил какой то надежности в его работе. Зато по импортозамещению Firebird = ред база данных, давно уже.

Каждая новая версия будет ломать об колено ваш код, в Лазарусе шесть компонентов в зависимости от версии!

Не уверен, но вроде zeos mysql ваш код ломать при смене версий не будут. Это не так?

[vitaly_l]

Чехарда с версиями. Каждая новая версия будет ломать об колено ваш код, в Лазарусе шесть компонентов в зависимости от версии!

Не уверен, но вроде zeos mysql ваш код ломать при смене версий не будут. Это не так?

По моему наоборот порядок с версиями. Номер совпадает с номером DLL - соответственно номер это всего лишь привязка к номеру DLL. Просто лазарус сохранил предыдущие версии, т.к. у многих подключение по старым DLL(при желании лазарус мог бы уместить всё в один модуль с выбором номера DLL). Если я ошибаюсь - поправьте.

.

[WAYFARER]

PostgreSQL скорее альтернатива Oracle по функциональности. Очень мощная и довольно сложная в освоении СУБД.
Если бизнес-логику собираетесь свешать на СУБД лучше выбрать Firebird для небольшого приложения. Если логика на стороне приложения - MySQL.
По поводу коммерческой лицензии MySQL. На сегодня она необходима только в одном, крайне редком случае:

При СТАТИЧЕСКОМ линковании программы с любым GPL кодом из ПО MySQL, в тех случаях, когда вы не хотите, чтобы готовый продукт подпадал под действие GPL (например, продукт разрабатывается как коммерческий или существуют какие-либо другие причины не открывать добавленный программный код, который не подпадает под действие GPL).

Т.е. проще говоря если вы не нарушаете условия GPL, то коммерческая лицензия не нужна.

Раньше все было несколько сложнее, до того как MySQL отошел Oracle, я вроде несколько лет назад выкладывал тут переписку с MySQL AB, но найти не получается.

[*Rik*]

Лучший вариант FireBird. Сверхкомпактен, при этом это полноценный SQL сервер с тразакциями, триггерами, хранимыми процедурами, вьюшками, может работать локально без установки сервера (embeded). По зубам любая база, у меня есть базы около 50 гб c сотней рабочих мест.
Компоненты под него запилил по типу FIBPlus: http://visual-t.ru/ibexpress.html

Но, для работы с FireBird, Вам нужно досконально усвоить все особенности использования его транзакций. В случае использования раздельных транзакций, обязательно изучить это: http://www.devrace.com/ru/fibplus/articles/2169.php

[debi12345]

Сверхкомпактен, при этом это полноценный SQL сервер с тразакциями, триггерами, хранимыми процедурами, вьюшками, может работать локально без установки сервера (embeded). По зубам любая база, у меня есть базы около 50 гб c сотней рабочих мест.

У SQLITE3 все это тоже есть.
Жарптичка все-таки требует некого шаманства с инсталляцией и ГОРАЗДО тяжеловеснее. Я бы в Вашем (однопользовательском) случае выбрал SQLITE3 - в 1ю очередь за компактность и простоту развертывания.
Еще важный момент- SQLITE3 можно при первой потребности превратить в щифрованную (целиком файлы) БД - просто заменив DLL-ку на умеющую щифровать (бесплатный SQLITE3 Cypher)

[azsx]

По зубам любая база, у меня есть базы около 50 гб c сотней рабочих мест.

Подскажите, нет ли у вас сбоев в работе или лома базы именно от FireBird?
Не могли бы вы уточнить сколько операций в пике нагрузке выполняется на вашей 50 гб базе и какая скорость (хоть образно)?

[debi12345]

Не могли бы вы уточнить сколько операций в пике нагрузке выполняется на вашей 50 гб базе и какая скорость (хоть образно)?

Человек же пишет что у него это одно-пользователская (локальная) БД - а значит тема "пик нагрузки" не стоИт

ПС: sqlite3-БЬД практически невозможно убить,если использовать ее с транзакциями. У меня есть проект на SQLITE в 8-ю инсталляциями - за 7...8 лет интенсивной работы ни одного падения БД, хотя за это время с компами (чисто мусор по "железу", без UPS-ов, вирус на вирусе) много что происходило.
В 1-ю очередь SQLITE3 (чистая а чаще в cypher-варианте) надежна потому что используется в смартфонах и планшетах - то есть на обширнейшей базе тестирования, плюс разрабам SQLIE3 за это капают немалые donate-денежки.