что выбрать для хранения нескольких тысяч записей в несколько килобайт.

[avm]

все. я пас! AmdY, сорри...

 

[Mikle Heavy]

Автор оригинала: avm
все. я пас! AmdY, сорри...

Я за хранение подобной структуры в БД.

Текстовые поля храним в поле тип text, если мы зависим от регистра - типа BLOB
Никто не отменял индексацию. При выборке по первичному ключу поиск уже ведется по индексу. Если выборка идет по содержимому записи - значит и его надо индексировать.
Большую нагрузку от SELECT на БД можно разложить на реплицируемые сервера. Если будет большое количество INSERT - смотрим в сторону кластера.
Рекомендую попробовать MySQL 5 или PosgreSQL

Варианты есть всегда.

А с тормозами на локальной машине - поиграйтесь с настройками сервера БД. При таком маленьком количестве записей (200 000 - это ерунда для БД) это проблемы с памятью, выделенной под серверный процесс.

 

[kruglov]

Mikle Heavy
Круто, на все готовы, на Posgre, на репликацию, на кластеры, только бы в файлах не хранить.

 

[Mikle Heavy]

Автор оригинала: kruglov
Mikle Heavy
Круто, на все готовы, на Posgre, на репликацию, на кластеры, только бы в файлах не хранить.

Огромный плюс при использовании реляционных СУБД - это поддержание не только физической целостности данных (чем обладает и файловая система), но и логической целостности. Кто будет следить за уникальностью имен файлов, кешированием\индексацией? Кроме того множественный доступ с модификацией файлов поднимет другую проблему - возможной взаимной блокировки (deadlock) при попытке одновременной записи в файл. Механизмы разрешения подобных конфликтов являются неотъемлемой частью СУБД. Потому и решения, которые должны обладать достаточно высокой степенью надежности для практической эксплуатации должны уметь это.