Davil SQLite удобно юзать в форумах-сайтах-итд, проблемы только 3 1 - В SQLite медленно делаются операции с DELETE, т.е хранить часто меняющиеся данные типа сессий и прочего придётся делать окуратно следя за нагрузкой в случае если на сайте десятки тысяч уников. 2 - В MySQL есть много вкусностей которых нет в SQLite... 3 - Файл базы придётся защищать (кидать в папку недоступную из вне или через htaccess) и проблема в том что мануалы обычно это умалчивают... В итоге для опытного программиста сложностей в этом не будет, по этому SQLite имхо хорошая СУБД просто не особо распространённая по этому придётся первое время привыкать...
Ti спасибо за линку. Vladson ну, впринципе, не вижу того, к чему привыкать, за исключением того, что SQLite - обрезанная по сравнению с MySQL, но на уровне интеграции с PHP она неплохо обустроена. Есть функции, которые убирают необходимости циклов при добыче инфы из базы. Это радует но, думаю нет особого смысла отказываться от MySQL на хостингах, на которых она есть...
1. В SQLite вообще медленно делаются операции изменения данный. При insert, например, у меня 0,1 сек. тратится на подготовку журнала транзакций и т.п. 2. И наоборот ) 3. Вменяемый человек и сам догадается.
Если запрос более-менее сложный (из более, чем двух таблиц и пяток условий во where), то SQLite уже не столь быстра, как при select id,name from mytable. Да и назначение этой БД - заменить привычный программистам на C (и иже с ним) dbase. Я лично не вижу смысла вообще использовать sqlite в web-программировании. Да, кстати, еще: SQLite - это исключительно локальная БД. Клиент-серверный механизм надо реализовывать собственноручно.
Davil, не вижу особого смысла отказываться от mysql в пользу sqlite и от sqlite в пользу mysql ). Они прекрасно работают вместе. Для частоизменяемых данных лучше mysql. А sqlite здорово работает при выборке данных.
AlexGousev это про то, когда база на другом хосте? Тогда просто указать путь к файлу на другом хосте, но это удар по безопасности...
Легко... MySQL есть по сути своей сервер, отдельная программа (демон), который запущен на каком-то компьютере. К этому серверу можно подключится как с локального компьютера, так и с любого другого (при наличии доступа, естественно). И потом посылать запросы. SQLite, напротив, есть просто файл. Т.е. при пользовании этой БД ты, по сути, просто делаешь fopen. Потом читаешь и пишешь данные в этот файл. Исходя из этого возникает две проблемы: Первая: необходим сервер, который будет контролировать права доступа. Вторая: необходим сервер, который будет разруливать попытки одновременного доступа нескольких клиентов. Обе эти проблемы решены в MySQL. И скорость работы БД в том числе и из-за этого несколько ниже при простых запросах.
Можно, но это не есть правильно. А вообще, самому это реализовывать нет смысла. Для этого есть множество готовых к использованию СУБД.
Зачем? В этом то и весь кайф. Что есть mysql-сервер, на котором куча баз данных различных пользователей и все эти пользователи лезут на этот сервер. И на этом сервере сложная система привилегий и ему приходится постоянно отслеживать, чтобы кто-нибудь на залез куда не надо. А есть sqlite-база, которая по-сути просто файл. Твой личный файл, который спрятал в закрытый каталог и не волнуют тебя больше никакие другие пользователи. Доступ там и разруливается, как обычный доступ к файлу. Через блокировки. И здесь возникают уже вышеописанные проблемы: при записи в файл (запросы на вставку/изменение/удаление данных) все начинает тормозит. Поэтому частоизменяемые данные там лучше не хранить. А при использовании sqlite в основном, как read-only, все летает.
На SQLite прикольно гостевушки и новостные скрипты делать, там запись/правка/удаление чего либо идёт очень редко, а в основном только чтение небольшими кусками...
Ня-ня-нё! Спор — ни о чем! Кесарю — кесарево! Каждый продукт лучше подходит под определенные нужды...