Из файлов быстрее, но не будет фич которые можно получить от БД

А есть какие-нить тесты, насколько быстрее?

Впринципе, думаю, для большинства задач это не принципиально, но хотелось бы посмотреть.

> Из файлов быстрее, но не будет фич которые можно получить от БД

не факт, все зависит от объема данных и настроек конкретной СУБД.

Могу предложить промежуточный вариант: SQLite :-)

> Могу предложить промежуточный вариант: SQLite :-)

+1

По-твоему БД бывают только реляционными и похожими на MySQL? Твои файлы, в которых ты что-то хранишь, это тоже БД. А БД, в свою очередь - это тоже файлы.

> Из файлов быстрее

Ой не факт, особенно если читать строки потребуется не по порядку, а по условию. Индексы такие индексы.

Единственный плюс файлов - возможность править вручную.

Мне, почему-то, кажется, что для этой задачи лучше подходит BDB.

> По-твоему БД бывают только реляционными и похожими на MySQL?

ну иерархические еще не умерли, покажи мне полную коммерческую реализацию ООСУБД.

> Твои файлы, в которых ты что-то хранишь, это тоже БД. А БД, в свою очередь - это тоже файлы.

внутреннее представление может хранится и в оперативной памяти как бэ.

Id в табличке индексировано?

> По-твоему БД бывают только реляционными и похожими на MySQL? Твои файлы, в которых ты что-то хранишь, это тоже БД. А БД, в свою очередь - это тоже файлы.

Ну дык, я же сказал про таблицы в БД.

> Id в табличке индексировано?

ну это уже вопросы реализации, а у меня интерес чисто теоретический.

это не принципиально
просто люди не понимают, что отказываясь от готовой БД, они обречены написать свою

> SQLite

дык он же на порядок медленнее того же mySQL

> Ну дык, я же сказал про таблицы в БД.

тссс, это школьник, который знает про Оракл и майскуль и скулайт. Ща он нам покажет как можно выгибать пальцы до локтей.

Ганс прав.

"Если вы используете дополнительный слой для хранения данных у вас просто плохая файловая система." (Г. Райзер)

>> SQLite

> дык он же на порядок медленнее того же mySQL

Во-первых, нифига. Во-вторых, ему не нужен сервер (в отличие от).

> просто люди не понимают, что отказываясь от готовой БД, они обречены написать свою

Ты тоже идиот, при больших объемах данных тебя ни одна СУБД не спасет, даже оракель.

> тссс, это школьник, который знает про Оракл и майскуль и скулайт. Ща он нам покажет как можно выгибать пальцы до локтей

не понял смысла фразы.

> Во-первых, нифига. Во-вторых, ему не нужен сервер (в отличие от).

первая ссылка в гугле

http://habrahabr.ru/blogs/webdev/42121/

Из файлов

>> Во-первых, нифига. Во-вторых, ему не нужен сервер (в отличие от).

> первая ссылка в гугле

> http://habrahabr.ru/blogs/webdev/42121/

По ссылке показано, что SQLite быстрее, чем MySQL. Ты об этом?

> тссс, это школьник, который знает про Оракл и майскуль и скулайт.

Настолько не предметный высер, что я даже не знаю, чего тебе ответить.

> Ты тоже идиот, при больших объемах данных тебя ни одна СУБД не спасет, даже оракель.

И как это противоречит утверждению, которое ты цитировал? Прими антидепрессантов, офисному планктону помогает.

> По ссылке показано, что SQLite быстрее, чем MySQL. Ты об этом?

это для win. Ниже в комментах тесты для linux

>> По ссылке показано, что SQLite быстрее, чем MySQL. Ты об этом?

> это для win. Ниже в комментах тесты для linux

Друх, да ты сам-то их читал? http://habrahabr.ru/blogs/webdev/42121/#comment_1037164

упс, пропустил

странный результат. Запустил ваш тест на своем dev сервере (Ubuntu Server, ядро 2.6, Apache 2, PHP 5.2.6) и получил тот результат на который, как я понял, вы надеялись:
SQLite:
0.0226039886475
0.0238060951233
0.0236310958862
0.015144109726
0.0120120048523
Average time:
0.019439458847

MySQL:
0.0117030143738
0.011342048645
0.0117700099945
0.0126521587372
0.0117499828339
Average time:
0.0118434429169

Количество итераций увеличено до 500:
SQLite
…
Average time:
0.0125000824928

MySql
…
0.0096476111412

я про это говорил

"Если вы используете дополнительный слой земли для хранения тайны, то у вас просто несвежая русская жена." (он же)

Эх, старый добрый итишный холиварчик "БД vs файлы". Что может быть лучше?

> Во-первых, нифига.

фигА-фигА. амарок поюзай с тем и с другим.

>не факт, все зависит от объема данных и настроек конкретной СУБД.

СУБД никогда не даст такой же производительности, как прямая работа с файлом.http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=526955&pg=1&...

http://www.sql.ru/forum/actualthread.aspx?tid=461153&pg=1#4513798

http://www.sql.ru/forum/actualthread.aspx?bid=36&tid=649460#6965529

http://www.sql.ru/forum/actualthread.aspx?tid=544606

http://www.sql.ru/forum/actualthread.aspx?bid=36&tid=629758#6676010

> Ниже в комментах тесты для linux

Это вроде как исправлено в 2.6.29.

http://www.sql.ru/forum/actualthread.aspx?bid=28&tid=629164#6667727

http://www.sql.ru/forum/actualthread.aspx?tid=619608&pg=1#6560282

>И есть директория с файлами с именами id, которые содержает plaintext text_value. Пусть есть скрипт, который должен считывать text_value по передаваемому значению id

открывать/читать/закрывать ради мелкого количества текста.. извращенно как-то..

У sqlite ещё всё ужасно на параллельных запросах.

Зависит от того, что потом с этим текстом делать.

Если прочитать, обработать, подставить в скрипт - то БД удобнее и быстрее.

Если отдать в браузер, например, готовую картинку, то файл будет на порядки быстрее.

От задачи и конкретных условий зависит.

Всё сильно зависит от реализации. В конце концов никто не мешает разместить базу данных непосредственно в памяти, попутно выкинув overhead файловой системы (многие субд это позволяют делать). А если к этому добавить удобство sql, то работа с файлами станет явно бесперспективным вариантом.

Всё зависит от задачи (ну и от количества файлов). Если данные константны (меняются очень редко) то по скорости, имхо, быстрее будут константные хеши (к примеру tinyCDB http://www.corpit.ru/mjt/tinycdb.html). Ещё быстрее будет: сделать индекс и смержить все данные в один файл. Индекс подгрузить в пямять, а файл читать через memory-mapped file или обычным чтением.

Если данные не константны - то неконстантные хеши (bdb, Die-Hard очень советовал tokyocabinet http://sourceforge.net/projects/tokyocabinet/). SQLite - в этом случае излишен.

Обычные базы данных не вариант.

Если делать на простых - то если хватает дискового кеша - надо прочитать их всех при загрузке программы. Они попадут в кеш и доступ будет очень быстрым.

> константные хеши

> tokyocabinet

Хренасе рецепты для _скрипта_.

> SQLite - в этом случае излишен.

Он в этом случа оптимален.

> для _скрипта_.

был не внимателен=)

А так:
 если        id : uniq integer
      text_value: varchar(N)

Все хранится в одном sparse-файле а-ля обычный массив с доступом по индексу --> О(1)

Прямой доступ к элементу:
    dd if=/db-array.file skip=ID bs=N count=1

Для работы с парами ключ-значения давным давно придумана такая штука, как Berkley DB. Автор, почитай про BDB - это то, что тебе надо.
Библиотеки под неё есть практически в каждом ЯП.