SQLIte, однако, изрядно сосёт.
1. Каждая таблица в SQLite обязательно имеет целочисленный ключ, явный или неявный. Несмотря на это, счёт элементов таблицы не ведётся и select count(*) from table на таблице из, скажем, нескольких тысяч записей - весьма дорогая операция.
2. Запрос типа SELECT * FROM big_table JOIN small_table ON big_table.f1=small_table.f2 WHERE big_table.id IN (SELECT id FROM other_table WHERE condition LIMIT 5) - очень долгий. То же самое, только сначала вручную внутренний SELECT, а потом вписать ручками результат в IN - быстро. Какая оптимизация, где?
3. Но это мелочи ещё. Вот поинтереснее: запрос типа SELECT * FROM big_table JOIN small_table ON big_table big_table.f1=small_table.f2 - выполняется медленнее, чем SELECT * FROM small_table JOIN big_table ON big_table big_table.f1=small_table.f2. Типа хотите оптимизатор запросов? Так сами себе и пишите.
4. EXPLAIN у них - тонкое издевательство. Зачем он вообще нужен, если выдаёт пачку непонятного никому, кроме автора, ассемблерного кода? Неужто так трудно сделать explain как в MySQL, хотя бы?
5. При больших запросах память жрёт, как собака, явно больше, чем выделено под его кеш. Хотя, может, это я не понял, как его определение кеша устроено.
6. Работает с базой из 100 тысяч, скажем, записей и 6 таблиц весьма медленно - возможно, из-за 2-3, хотя из-за 4 даже выяснить это можно только экспериментальным путём.
Мне, конечно, скажут - за что заплатил, то и получил. Тоже верно. Но судя по их сайту, ожидалось гораздо лучшего.
1. Каждая таблица в SQLite обязательно имеет целочисленный ключ, явный или неявный. Несмотря на это, счёт элементов таблицы не ведётся и select count(*) from table на таблице из, скажем, нескольких тысяч записей - весьма дорогая операция.
2. Запрос типа SELECT * FROM big_table JOIN small_table ON big_table.f1=small_table.f2 WHERE big_table.id IN (SELECT id FROM other_table WHERE condition LIMIT 5) - очень долгий. То же самое, только сначала вручную внутренний SELECT, а потом вписать ручками результат в IN - быстро. Какая оптимизация, где?
3. Но это мелочи ещё. Вот поинтереснее: запрос типа SELECT * FROM big_table JOIN small_table ON big_table big_table.f1=small_table.f2 - выполняется медленнее, чем SELECT * FROM small_table JOIN big_table ON big_table big_table.f1=small_table.f2. Типа хотите оптимизатор запросов? Так сами себе и пишите.
4. EXPLAIN у них - тонкое издевательство. Зачем он вообще нужен, если выдаёт пачку непонятного никому, кроме автора, ассемблерного кода? Неужто так трудно сделать explain как в MySQL, хотя бы?
5. При больших запросах память жрёт, как собака, явно больше, чем выделено под его кеш. Хотя, может, это я не понял, как его определение кеша устроено.
6. Работает с базой из 100 тысяч, скажем, записей и 6 таблиц весьма медленно - возможно, из-за 2-3, хотя из-за 4 даже выяснить это можно только экспериментальным путём.
Мне, конечно, скажут - за что заплатил, то и получил. Тоже верно. Но судя по их сайту, ожидалось гораздо лучшего.