Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

SQLite или Firebird?

5.7K
03 августа 2011 года
Lindemann66
193 / / 21.07.2011
Всем привет!

В разрабатываемом приложении необходимо хранение данных
К возможным вариантам сразу ставится ограничение - сервера быть не должно
Поискав и поспрашивав на форумах, я пришёл к выводу, что наиболее подходящие вещи - это

SQLite и Firebird
Обе легковесны, не требуют установки сервера

Есть, конечно, ещё Berkeley DB, гугловская база, также основанная на ключ-значение

Но в этом я разбираюсь плохо (в такого рода "архитектуре", основанной на
Цитата:
хранении пары ключ/значение как массивы байтов

, и в силу субъективного мнения считаю, что стандартное представление данных, как в SQLite, лучше)

Правда, опыта в использовании ни SQLite, ни Firebird, не имею

Может, кто-то подскажет какие-то моменты относительно этого выбора?
Я читал статьи вроде Сравнание СУБД
или
SQLite vs Firebird

В них, всё же, отдаётся предпочтение Firebird. Но хотелось бы услышать мнение сообщества, так ли это, что Firebird более предпочтителен?

10
03 августа 2011 года
Freeman
3.2K / / 06.03.2004
Нужно учитывать, что Firebird создавался как полноценный сервер. Его умение работать в качестве встроенного -- приятное дополнение, не более. SQLite -- наоборот, чисто встраиваемая СУБД, -- для тех, кому "ключ=значение" уже не хватает.

В Firebird есть всё, что есть в любой другой полноценной СУБД: представления, триггеры, скриптовый язык для них и т. п. Кроме того, Firebird намного старше SQLite, и поэтому кое-где консервативен. Об этом и говорят в комментариях.

Выбирать нужно из того, насколько важна машстабируемость. SQLite обычно используется для небольших БД. Скажем, у нас на работе он используется для хранения контактов Jabber-сервера. Не знаю, как SQLite поведёт себя при сколько-нибудь значительной нагрузке -- сотни мегабайт, гигабайты. С Firebird настолько плотно не работал, но думаю, что справится. Хотя, если ваш размер -- гигабайты, стоит подумать о серьёзной СУБД, вроде PostgreSQL.
5.7K
03 августа 2011 года
Lindemann66
193 / / 21.07.2011
Понятно, спасибо :)
P.S. Сегодня на обсуждении сделали выбор в пользу SQLite
7
03 августа 2011 года
@pixo $oft
3.4K / / 20.09.2006
Есть ещё JET Blue(оно же Extensible storage engine)
Даже ничего таскать с собой не надо
10
03 августа 2011 года
Freeman
3.2K / / 06.03.2004
Цитата: @pixo $oft
Есть ещё JET Blue(оно же Extensible storage engine)


А вот это -- не надо. Уж лучше открытый SQLite, чем этот недо-Access. Тем более, что SQL-ем там даже и не пахнет. Тогда даже не SQLite, а "ключ-значение" лучше будет. И ничего таскать не надо, ага.

7
03 августа 2011 года
@pixo $oft
3.4K / / 20.09.2006
Ну почему сразу не надо?Копаться в исходниках ему не надо,SQL вроде тоже не нужен(он данные хранить хотел)
Красотисча!Даже поиск есть
6
03 августа 2011 года
George
4.1K / / 05.01.2007
У нас были файрбёрдовские БД размером с 2Гб - нормально пахало. Меня там больше бесит отсутствие вменяемого административного софта.

Зы. Што-то не там ветку создали, перенести надо бы.
Ззы. Постгрес тоже есть embedded версии емнип.

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог