SQLite или Firebird?
Всем привет!
В разрабатываемом приложении необходимо хранение данных
К возможным вариантам сразу ставится ограничение - сервера быть не должно
Поискав и поспрашивав на форумах, я пришёл к выводу, что наиболее подходящие вещи - это
SQLite и Firebird
Обе легковесны, не требуют установки сервера
Есть, конечно, ещё Berkeley DB, гугловская база, также основанная на ключ-значение
Но в этом я разбираюсь плохо (в такого рода "архитектуре", основанной на
В разрабатываемом приложении необходимо хранение данных
К возможным вариантам сразу ставится ограничение - сервера быть не должно
Поискав и поспрашивав на форумах, я пришёл к выводу, что наиболее подходящие вещи - это
SQLite и Firebird
Обе легковесны, не требуют установки сервера
Есть, конечно, ещё Berkeley DB, гугловская база, также основанная на ключ-значение
Но в этом я разбираюсь плохо (в такого рода "архитектуре", основанной на
Цитата:
хранении пары ключ/значение как массивы байтов
, и в силу субъективного мнения считаю, что стандартное представление данных, как в SQLite, лучше)
Правда, опыта в использовании ни SQLite, ни Firebird, не имею
Может, кто-то подскажет какие-то моменты относительно этого выбора?
Я читал статьи вроде Сравнание СУБД
или
SQLite vs Firebird
В них, всё же, отдаётся предпочтение Firebird. Но хотелось бы услышать мнение сообщества, так ли это, что Firebird более предпочтителен?
Нужно учитывать, что Firebird создавался как полноценный сервер. Его умение работать в качестве встроенного -- приятное дополнение, не более. SQLite -- наоборот, чисто встраиваемая СУБД, -- для тех, кому "ключ=значение" уже не хватает.
В Firebird есть всё, что есть в любой другой полноценной СУБД: представления, триггеры, скриптовый язык для них и т. п. Кроме того, Firebird намного старше SQLite, и поэтому кое-где консервативен. Об этом и говорят в комментариях.
Выбирать нужно из того, насколько важна машстабируемость. SQLite обычно используется для небольших БД. Скажем, у нас на работе он используется для хранения контактов Jabber-сервера. Не знаю, как SQLite поведёт себя при сколько-нибудь значительной нагрузке -- сотни мегабайт, гигабайты. С Firebird настолько плотно не работал, но думаю, что справится. Хотя, если ваш размер -- гигабайты, стоит подумать о серьёзной СУБД, вроде PostgreSQL.
В Firebird есть всё, что есть в любой другой полноценной СУБД: представления, триггеры, скриптовый язык для них и т. п. Кроме того, Firebird намного старше SQLite, и поэтому кое-где консервативен. Об этом и говорят в комментариях.
Выбирать нужно из того, насколько важна машстабируемость. SQLite обычно используется для небольших БД. Скажем, у нас на работе он используется для хранения контактов Jabber-сервера. Не знаю, как SQLite поведёт себя при сколько-нибудь значительной нагрузке -- сотни мегабайт, гигабайты. С Firebird настолько плотно не работал, но думаю, что справится. Хотя, если ваш размер -- гигабайты, стоит подумать о серьёзной СУБД, вроде PostgreSQL.
Понятно, спасибо :)
P.S. Сегодня на обсуждении сделали выбор в пользу SQLite
P.S. Сегодня на обсуждении сделали выбор в пользу SQLite
Есть ещё JET Blue(оно же Extensible storage engine)
Даже ничего таскать с собой не надо
Даже ничего таскать с собой не надо
Цитата: @pixo $oft
Есть ещё JET Blue(оно же Extensible storage engine)
А вот это -- не надо. Уж лучше открытый SQLite, чем этот недо-Access. Тем более, что SQL-ем там даже и не пахнет. Тогда даже не SQLite, а "ключ-значение" лучше будет. И ничего таскать не надо, ага.
Ну почему сразу не надо?Копаться в исходниках ему не надо,SQL вроде тоже не нужен(он данные хранить хотел)
Красотисча!Даже поиск есть
Красотисча!Даже поиск есть
У нас были файрбёрдовские БД размером с 2Гб - нормально пахало. Меня там больше бесит отсутствие вменяемого административного софта.
Зы. Што-то не там ветку создали, перенести надо бы.
Ззы. Постгрес тоже есть embedded версии емнип.
Зы. Што-то не там ветку создали, перенести надо бы.
Ззы. Постгрес тоже есть embedded версии емнип.