http://php.su/articles/?cat=phpdb&page=038

Основные преимущества использования SQLite

Распространяется бесплатно.
Я упал.

Простота установки.
Прощё чем нажать пару раз next как в mysql.. Здорово.
Оно замо за меня нажимает..

Легкость администрирования.
Кто там писал SQLiteMenager/ Зачем?
Когда вы разрешали пользователю создавать для себя бд, да в любом количестве?


Простота использования.
Не перетрудитесь написать тип поля.
Не смотря на то что такие поля как Enum, Set, datetime не существуют..

Производительность.
По данным тестирования - www[dot]hwaci[dot]com/sw/sqlite/speed[dot]html
Вот что там написанно:

Note: This document is old. It describes a speed comparison between an older version of SQLite against archaic versions of MySQL and PostgreSQL. Readers are invited to contribute more up-to-date speed comparisons on the SQLite Wiki.

Легкая переносимость
Два фала не донесу. Потеряются.
Mysql совместима только с ДОСом..
Если ваш хостер не устравивает резервное копирование:


Объектно-ориентированный интерфейс.
Что за высокоэффективные, легко расширяемые приложения?

Ограничения использования SQLite

Без коментариев ...

Типы полей появились?

--
Нужный вывод я не получил.
Поможешь?

MySQL работает через сетевую подсистему (сокеты), а SQLite напрямую с файлами БД на диске через эффективный интерфейс. Отсюда скорость выше при работе с базами данных среднего уровня.
Согласен, что масштабируемость никуда не годится, но и SQLite не для этого был создан.
Очевидные плюсы SQLite:

1) Высокая производительность при работе с небольшими и средними БД (уже сказал);
2) Преимущество в легкой переносимости фалов баз данных. Особенно актуально, если хостер не разрешает экспортировать базы MySQL или ставит ограничения;
3) Нет ограничений на число соединений с БД, числа запросов к БД при размещении на стандартном виртуальном хостинге. Например, при работе с MySQL мой хостер устновил ограничения на 28000 соединений с БД в час и не более 50 одновременных соединений... А при использовании SQLite таких ограничений просто нет!

У меня MySQL работает через TCP

2) Преимущество в легкой переносимости фалов баз данных. Особенно актуально, если хостер не разрешает экспортировать базы MySQL или ставит ограничения;

Ну по ходу дела надо менять хостера если он не позволяет экспортировать БД.


А переносимость, Намного медленней если у тебя большие файлы
и много таблиц.

Ну насчёт подключений - согласен, но помойму никто столько подключений к базе в час не выжимает..
А вот 50 одновременных соединений.. хм.
Только если SQLite основан на файлах
то одновременно 50 чтений и записей ни к чему хорошему не приведут.

А если интересует скорость то намного быстрей работать напрямую с файлами из скриптом а не используя для этого ещё и SQLite..

мне кажеться продукт SQLite спешал фром ленивых, ведь дейсвтительно свой парсер будет работать с файлами достаточно быстро. Хотя При большой нагрузке на сайт (посетителей) возникнут трудности с чтением и записью. А если еще и пытаться создавать индексевые структуры то еще и индексы будут рушеться, это так же касается и SQLite.

Такие дела.

Очень сомневаюсь! Считай сам. Файлы с диска читаются довольно медленно. Один файл БД SQLite будет обрабатываться быстрее чем несколько простых текстовиков. Да и скрипты не будут перегружены мусором, т.к из БД выбираются только необходимые данные, а не вся БД, как при работе с файлами.

Согласен с f0rm4t, в SQLite применяются эффективные методы оптимизации, а с файлами получается все слишком примитивно...

Ну тогда весь мусор который находится у тебя в скрипте находится в движке БД
так что на скорость это вроде не влияет
Это ты в результате запроса получишь только нужные данные
а движку придётся читать весь файл.
Кстати, не подскажете эффективные методы оптимизации?

А, кстати в той статье я прочитал что sqlite хранит инфу в обычных текстовых фалах кажется..\n\n(Добавление)

Движку в любом случае придется читать весь файл!

Это означает не в бинарных файлах. БД SQLite можно открыть блокнотом и выдернуть от туда некоторые запросы. Только, опять же, смысла открывать текстовым редактором БД нет.

Ну с этим то я согласен,
я толоько не понимаю как выходит что такая связка:
скрипт - sqlite - file
работает быстрее чем
скрипт - file

Пример:
Есть БД SQLite с данными пользователей какого-нить форума.
И еще одна БД текстовый файл с подобным содержимым.
Есть скрипт для просмотра инфы о пользователях.
В первом случае, скрипт выполнит запрос, в результате которого будет выбрана только одна нужная запись.
Во втором скрипту придется перебирать все записи в файле, пока он не найдет нужную.
Теперь понятно?

Перебор записей будет аналогичен перебору файла.



См. выше.

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

В Гугле инфа храниться не в БД, а в "плоских" файлах, чем и объясняется быстрота его работы, так что вопрос очень спорный ...

To Format
мы уже как то обсуждали что это ты в скрипт получаешь только одну строку а так перебор фала за тебя делает движок базы
так что перебор никуда не девается.

"Движек базы" сделает это гораздо быстрее, нежели скрипт. Т.к. библиотеке не нужно интерпретироваться.

SQLite – это библиотека, написанная на языке C, реализующая SQL механизм работы с данными, другими словами, движок баз данных.

Ты кстати о какой библиотеке или
почему ей не надо интерпретироваться?