Возник вопрос по скорости и удобству...

есть текстовая база новостей

id|заголовок|текст|счетчик просмотров
1|заг1|текст1|0
2|заг2|текст2|2
3|заг3|текст3|5
4|заг4|текст4|0

читаю построчно и вывожу к примеру только заголовки с указанием количества просмотров.

далее если пользователь жмет подробнее, то открываю уже текст и увеличиваю кол-во просмотров, но для этого порой приходиться перечитываться весь файл, искать нужный id у него менять кол-во просмотров и опять писать все обратно.

впорос в чем, как будет быстрее и надежнее (так как в php flock из рук вон плох), хранить счетчики? может стоит их вынести для каждого id в отдельный файл? типа id.count
но тогда при показе кратких (заголовок кол-во просмотров) прийдется для каждой новости перечитывать каждый файл!

что вы думаете по этому поводу?

mysql не предлогать

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

Long, логичнее, но дублирование заголовков как-то не то...
да и все равно при показе заголовков все равно будет читаться каждый счетчик, это сильно медленно на пхп? (file)

либо я чего-то не понимаю, либо одно из двух...
у тебя есть файл с заголовками новостей формата
id|заголовок
и есть набор файлов с новостями. где на первой строке стоит счетчик просмотров, а со второй строки идет текст самой новости.

MpaK999, а не пробовал сделать через dBase functions или dbm functions, т.е. через базу данных, которая в файле лежит?

Long, все равно ведь при показе к примеру списка заголовков новостей по формату крый ты предлогаешь
надо прочитать файл со всеми заголовками
выводить по одной при этом открывая и читая файл со счетчиком (чтобы показать Новость (читали: 5 раз))
и т.д.

не долго ли это?

@TSV, на сколько я понимаю, это не решит проблему со счетчиком. и не факт, что на такой простой задаче будет работать быстрее. и потом, надо чтобы хостинг поддреживал dBase

MpaK999, ты должен отображать значение счетчика при показе заголовка?

Long, очень желательно.

я просто думаю, как будет лучше сделать (по скорости и удобству), чтобы счетчик лежал в общем файле новостей (к примеру) или отдельно...

Long, почему - не решит проблему со счетчиком? dBase, подумамши, я действительно из списка вычеркиваю. Ну а DB2? Которая базу в просто в файле держит к тому же. У нее-то проблем со скоростью, в общем-то нету никаких.

в 1ом случае сомнение во flock
во 2ом скорость чтения счетчиков для каждой новости

MpaK999, как говорилось в одном анекдоте - точнее надо было формулировать задачу...

сразу же написал "читаю построчно и вывожу к примеру только заголовки с указанием количества просмотров." см. первый пост

Проверил. Данная задача изумительно хорошо и просто (и быстро по скорости) решается через dbm Functions - abstraction layer для баз данных key=>value (i.e. Беркли DB). С самыми разными handlers, что ndbm, что db2 далее везде.

Таблицы titles(id=>title), news(id=>content), counters(id=>counter).

советую не маяться с текстами типа значение :: значени1 1
если уже и делаешь на текстовых - массив сериализованый- самое то.. намного меньше проблем с записью значени й счетчика, замене значений из под скрипта.. и никакого геморроя с добавлением новых значений.

@TSV, у dbm вроде зависимость от платфоры есть, размер базы...

MpaK999, нету у нее такой зависимости. И, строго говоря, dbm - это даже не база, dbm - это абстракция, интерфейс доступа, который полностью закрывает от тебя реализацию. Бинарные файлы базы, вероятнее всего, не будут переноситься. Но ведь тебя никто и не заставляет переносить именно бинарные файлы.

"Размер, количество и вид ключей и значений в DBM-базе данных ограничены. "

отсюда взято - http://webmaster.yartop.ru/progr/perl/p … 07-21.html

ну и вообще, отходим от темы... хотел бы базу использовал бы MySQL, так ведь вопрос в другом... как хранить эти счетчки, как удобнее и быстрее???

MpaK999,

Цитата:

Проверил. Данная задача изумительно хорошо и просто (и быстро по скорости) решается через dbm Functions - abstraction layer для баз данных key=>value (i.e. Беркли DB). С самыми разными handlers, что ndbm, что db2 далее везде. Таблицы titles(id=>title), news(id=>content), counters(id=>counter).

Не отходим. Это быстрее и MySQL, и текста.

@TSV, ок, быстро... но как бы с flock (DBM как я понял сам за этим следит?) и с ограничением на размер?

MpaK999,
- следит сам
- у DBM нету ограничения на размер. Точнее есть, но точное такое же, как и у любой строки PHP, то есть тебя волновать не будет в любом случае. Дело в том, что dbm - это abstraction layer, интерфейс, который вызывает уже реальные функции той базы, которая у тебя установлена (читай - прикомпилена к PHP).

Смотри разделы db и dba в выдаче phpinfo(); Handlers бывают разные, у подавляющего большинства ограничения весьма гуманные. Но за все, конечно, поручиться нельзя. Зато можно легко проверить. Затолкай в тестовую базу пару key=>value, у обоих задай большую длину. Затем вытащи обратно и сравни.

А в той книжке, во-первых, написано про Perl, во-вторых, автор так четко и ясно назвал ограничения, как будто бы у всех одинаковые handlers стоят. Смех и грех.

Примечательный факт - Илья Сегалович (один из разработчиков Yandex) не так давно обмолвился на форуме Yandex, что они перестали использовать собственноручно написанную базу для хранения индексов, и пересели на Berkley DB. По нашему, по-бразильски, это интерфейс dbm к handler DB2. Ограничений не забоялись, что харАктерно. Неужели у тебя объемы информации больше, чем у Yandex.

@TSV, ок, все же убедил, что 4 гигов базы мне разумеется хватит

но вопрос не стоит переходить с текстов или нет на DBM

вопрос в другом... (см. начало)

где хранить счетчики просмотров (новостей, статей, фотографий и т.п.), в общем файле (опасность плохого flock), но быстро когда выводишь заголовок и счетчик...

или же в каждый в отдельном файле, flock не страшен, но при выводе заголовков, для каждого надо читать его файл со значением счетчика, чтобы показать это.…


ТАК КАК ЖЕ ВСЕ?

MpaK999, уточняющий вопрос - т.е. именно только с использованием просто текстовых файлов, никакую базу ты использовать не хочешь. ТОЧНО?

@TSV, так точно

MpaK999, О! Тогда используй счетчик как часть имени файла.
- Имя файла <NNN>.<дата>.<время>. <счетчик>.txt - новость
- При увеличении счетчика делаем просто rename()
- В файле первая строка - заголовок, остальное - сама новость
- При выводе списка новостей получаем список из имени файла и его первой строчки
- Никаких lockов и в помине нету. Только нужно вызывать @rename().

@TSV, идея прикольная...
а как узнавать имена файлов (opendir)? тогда как им задавать порядок - сортировать по <NNN>?

@TSV, а как определять имя файла в текущий момент?

MpaK999, - opendir(), сортировать по <NNN>, у меня, кстати, сделано без счетчика, а просто дата и время составляют часть имени файла, по ним и сортирую. Но не суть. Как хошь, так и сортируй.
Long, - chdir($newsdir); glob(<имя файла с '*' вместо счетчика>)
MpaK999, а можно и просто

MpaK999, важная инфа насчет glob():

Цитата:

glob (PHP 4 >= 4.3.0) glob -- Find pathnames matching a pattern Description array glob ( string pattern [, int flags]) The glob() function searches for all the pathnames matching pattern according to the rules used by the shell. No tilde expansion or parameter substitution is done. Returns an array containing the matched files/directories or FALSE on error. Note: Before PHP 4.3.3 GLOB_ONLYDIR was not available on Windows and other systems not using the GNU C library.

http://www.php.net/manual/en/function.glob.php
Второе тебя, скорее всего, волнует меньше, а первое - существенно.

думаю, что еще должно волновать

Цитата:

This function is disabled in safe mode

Long, но ведь это бывает все-таки редко. Не все ж провайдеры такие звери.

хорошая идея... сегодня сделаю пару тестов на скорость...

@TSV, не скажи, точной статистики не знаю, но предполагаю, что больше половины ставит сейфмод. (тот же SiteHotel)

вчера за пару минут сделал тестовые скрипты.…

база 1359 записей, гонял по 10000 раз, потом взял среднее время работы...

разница между вариантами счетчик внутри и счетчик снаружи - 01.0967519 и 01.11027661

тест - http://mpak.bestweb.ru/des/test.rar - 100Kb
возможно он и не совсем корректный...

очень, сорри.. поправил урл

MpaK999, 404 not found.