Вышел (http://sqlite.org/releaselog/3_6_12.html) релиз SQLite 3.6.12 в котором исправлена ошибка, которая могла привести к повреждению данных при отмене выполнения vacuum в момент обработки базы, хранимой в ОЗУ; Кроме того:

-  добавлен интерфейс sqlite3_unlock_notify(), -  добавлен pragma-параметр reverse_unordered_selects, -  в CLI интерфейсе появилась команда ".genfkey" для генерации триггеров для реализации заданного внешнего ключа, -  улучшена производительность запросов с "count(*)", -  уменьшено потребление памяти при работе триггеров.

URL: http://sqlite.org/releaselog/3_6_12.html
Новость: http://www.opennet.me/opennews/art.shtml?num=21051

• Вышел релиз SQLite 3.6.12,аноним, 22:32 , 01-Апр-09
  • Вышел релиз SQLite 3.6.12,Аноним, 23:11 , 01-Апр-09
    • Вышел релиз SQLite 3.6.12,Ян Злобин, 04:14 , 02-Апр-09
      • Вышел релиз SQLite 3.6.12,Аноним, 10:22 , 02-Апр-09
        • Вышел релиз SQLite 3.6.12,bobah, 13:24 , 02-Апр-09
    • Вышел релиз SQLite 3.6.12,Аноним, 06:44 , 02-Апр-09
      • Вышел релиз SQLite 3.6.12,svn, 10:04 , 02-Апр-09
        • Вышел релиз SQLite 3.6.12,bobah, 13:26 , 02-Апр-09
• Вышел релиз SQLite 3.6.12,Аноним, 05:40 , 02-Апр-09
  • Вышел релиз SQLite 3.6.12,Aleksey, 10:14 , 02-Апр-09
  • Вышел релиз SQLite 3.6.12,eugen, 10:19 , 02-Апр-09

Там все также запросы вида like "abc%" не умеют использовать индексы?

>Там все также запросы вида like "abc%" не умеют использовать индексы?

IMHO, ни одна СУБД такое не умеет, при like запросах всегда перебираются все записи. Как вариант, можно оптимизировать подобное через полнотекстовые индексы в PostgreSQL и MySQL.

>IMHO, ни одна СУБД такое не умеет, при like запросах всегда перебираются
>все записи. Как вариант, можно оптимизировать подобное через полнотекстовые индексы в
>PostgreSQL и MySQL.

PostgreSQL как раз умеет использовать индексы с LIKE без полнотекстового поиска.

>PostgreSQL как раз умеет использовать индексы с LIKE без полнотекстового поиска.

А вы посмотрите explain'ом, он всегда делает Seq Scan по основной таблице.

explain select login from user_param where login like 'user%';

Seq Scan on user_param (cost=0.00..1433.40 rows=36 width=11)
   Filter: (("login")::text ~~ 'user%'::text)

explain select login from user_param where login ~ '^user';

Seq Scan on user_param  (cost=0.00..1433.40 rows=36 width=11)
   Filter: (("login")::text ~ '^user'::text)

explain select login from user_param where login = 'bob';

Index Scan using profile_pkey on user_param  (cost=0.00..8.28 rows=1 width=11)
   Index Cond: (("login")::text = 'bob'::text)

PostgreSQL 8.2. Для логин "login" создан btree индекс, записей в таблице тысяч 50.

>[оверквотинг удален]
>   Filter: (("login")::text ~ '^user'::text)
>
>explain select login from user_param where login = 'bob';
>
> Index Scan using profile_pkey on user_param  (cost=0.00..8.28 rows=1 width=11)
>   Index Cond: (("login")::text = 'bob'::text)
>
>
>PostgreSQL 8.2. Для логин "login" создан btree индекс, записей в таблице тысяч
>50.

при создании индекса юзайте оипцию varchar_pattern_ops и будет вам щастье like 'happy%'

>IMHO, ни одна СУБД такое не умеет

Да что вы? На btree индексах like "abc%" это абсолютно то же самое, что и ="abc". Не уметь такое стыдно.

>Да что вы? На btree индексах like "abc%" это абсолютно то же
>самое, что и ="abc". Не уметь такое стыдно.

Вовсе не тоже самое. строки сравниваются по правилам локализации, и это (кроме локалей C и POSIX) не совпадает с побайтным сравнением.

Не говоря уже об уникоде с его выкрутасами.

при создании индекса юзайте оипцию varchar_pattern_ops и будет вам щастье like 'happy%'

Какую программу использовать для визуального редактирования БД  

Для ФареБирда есть IBExpert, для MySQL есть EMS MySQL Manager,

а для sqlite?

>Какую программу использовать для визуального редактирования БД
>
>Для ФареБирда есть IBExpert, для MySQL есть EMS MySQL Manager,
>
>а для sqlite?

SQLite Manager
https://addons.mozilla.org/en-US/firefox/addon/5817

>Какую программу использовать для визуального редактирования БД
>для sqlite?

Под Qt есть sqliteman