>[оверквотинг удален]
>Если вы такой умный - придумайте разумный сценарий под которой sqlite не
>хватит.Не забывая про чижика с sql.ru который 20 гиговую базу в
>sqlite в продакшне содержит без особых проблем.Если у меня только база
>коллекции станет порядка несколько гигов - сколько же весит сама коллекция?По-моему
>чтобы базу настолько отрастить - надо индексировать все mp3 интернета в
>ней.Никак не меньше.И проблем я вот чесслово не испытывал.С несколькими тысячами
>наименований.В результате более жирный мускуль просто не выглядит оправданым для ВСЕГО
>ЛИШЬ ПЛЕЕРА.Это не гугл, мля.Там и sqlite то с пятерным запасом
>было(тем более что при грамотном юзеже sqlite сливать мускулю как-то ни
>разу не собирается как-бы).

Вот тут все по полочкам:
http://amarok.kde.org/blog/archives/812-MySQL-in-Amarok-2-Th...

В частности (да простят мне вольный перевод; кому не нравится -- линк на оригинал выше):

Проблема 1: производительность. SQLite достаточно производительная при небольших коллекциях. Но те из пользователей больших коллекций, которые не поленились опробовать MySQL, либо Postgre SQL (в первом амароке), сообщали об огромном (enormous) увеличении производительности при выполнении сложных и/или множественных запросов, таких как:
- добавление множества пунктов в список воспроизведения
- сканирование файлов
- фильтрация/поиск в коллекции.

Так как нашей цельню является удовлетворение потребностей пользователей больших коллекций, ровно так же как и пользователей с небольшими, и т.к. архивы цифровой музыки как правило *не становятся меньше*, увеличение скорости для пользователей с большими архивами является очень важной задачей.

Многие наши программисты, после перехода на mysqle (так мы ее называем, хоть это и не официальное обозначение), тоже заметили значительное ускорение при ежедневном использовании Amarok 2. Т.е., встроенное решение вполне себе заменяет отдельный MySQL сервер.

Проблема 2: назначение SQLite (поговорим об универсальности). Многие пользователи (включая меня) имеют несколько компьютеров, подключеных к одной базе Amarok'а. Предполагая что все компьютеры имеют доступ к музыке, расположенной в одной и той же точке монтирования (также имеются еще несколько правильных настроек), у вас появляется возможность сканировать единожды, проигрывать везде, обновлять рейтинги, етц - и все будет фиксироваться в одном месте. Даже если не стоит задача расшариваеть БД для нескольких компьютеров, многие пользователи все-равно хотят иметь БД на определенном сервере из соображений скорости, безопасности и более централизованного резервного архивирования. Если вы считаете что все вышеперечисленное не является распространенным, вы несколько ошибаетесь. MySQL и PostgreSQL всегда прекрасно спавлялись с подобными примерами использования. SQLite же полностью исключает их, т.к. была разработана для других целей.

Т.о., у SQLite уже два минуса.

Но, также как мы не можем полагаться на пользователя, что он в состоянии правильно настроить Strigi/Nepomuk, мы не можем полагаться и на то, что он справится с настройками MySQL или PostgreSQL. Т.о., нам нужно встроенное решение, которое будет "просто работать". Для MySQL такая возможность имеется (некоторые начинания есть уже в v4.1.x; полная поддержка ожидается к 5.1 (AFAIK)). У PostgreSQL подобных решений нет вообще (хотя имеется интересный концепт).

Так что мы остаемся с -- как вы могли догадаться -- MySQL. Это может не быть любимой ДБ каждого (хотя для многих - она такой является), и я даже не знаю сколько скрытых проблем во встраиваемое реализации данной ДБ, но она удовлетворяет основным требованиям. Он может быть как втроенной, так и доступной по сети (да, на данный момент нет такой возможности в Amarok 2, но она появится). Она достаточно производительная для больших коллекций. И, самое главное, она позволяет использовать один backend, который будет удовлетворять все наши требования.

Если вы все еще недовольны нашим решениям, я прошу прощения. Мы пытаемся удовлетворить больгинство, но мы не можем удовлетворить каждого. Также, мы те, кто разрабатывает и поддерживает данное приложение, и поэтому мы делали выбор не только на основании коллективных отзывов тысяч пользователей, но и для собственного удобства в том числе. Пожелуйста помните, что даже если большинство комментов к этой статье будет содержать негативные отзывы, на самом деле данное решение удовлетворит подавляющее большинство наших пользователей намного лучше, чем любое из тех, которые мы могли бы использовать на данный момент.