Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Перехват события открытия, записи, закрытия файла
 
 автор: Valleri   (11.02.2012 в 22:31)   письмо автору
 
 

Допустим есть тикеты, или просто добавлены файлы, для записи в них информации при некоторых событиях
На практике предполагается, что информационные файлы будут добавляться по мере дальнейшего роста пользователей и их деяний, требующих контроля.
Так как количество файлов будет возрастать, то встает вопрос об оптимальном механизме (логировании, централизованном контроле)записи добавления в разные файлы.
Конечно, если иметь в виду Субд, то кажется, что вопрос автоматически решается.
Но на самом деле, часто надо предоставить контрольные точки и вставка, частые вставки, в СУБД прогнозирует хаотический рост таблиц !!! Вдобавок надо права доступа предоставлять всем модераторам, что увеличивает общие риски.
Если не оспаривать цель создания временных или начальных небольших накопителей , хранилищ отслеживающих определенные события, то как перехватить гарантированно открытие, запись в файл, закрытие файла не производя непосредственных записей кода в скрипте.

   
 
 автор: cheops   (11.02.2012 в 22:45)   письмо автору
 
   для: Valleri   (11.02.2012 в 22:31)
 

>в СУБД прогнозирует хаотический рост таблиц !!!
Только при неправильном проектировании. Да есть соблазн наплодить кучу таблиц, но можно обойтись ограниченным количеством, если все по-нормальному спроектировать.

>то как перехватить гарантированно открытие, запись в файл, закрытие файла не производя
>непосредственных записей кода в скрипте.
На уровне PHP этого сделать нельзя. Более того, вам придется создать собственную мини-СУБД, чтобы организовать очередь, не побить файлы, и не снизить производительность блокировками (причем на PHP опять же, вам это толком не удастся). Лучше используйте готовую СУБД, вы даже не представляете насколько титаническая работа проделана в любой современной СУБД (те вопросы, которые вас волнуют сейчас их волновали 20 лет назад).

   
 
 автор: Valleri   (12.02.2012 в 15:54)   письмо автору
 
   для: cheops   (11.02.2012 в 22:45)
 

При всем моем уважении, скажу что на многих сайтах часто пишут НЕЗЗЗЯЯЯ.
Интересный аргумент- НЕЗЗЗЯЯЯ.
Очень весомый но обращен к личности а не к реальности.

У меня студент был, который рассуждал иначе:"Если бы я создавал систему, то обязательно добавил такую возможность"
Ему говорили НЕЗЗЗЯЯЯ.
Самое удивительное, что он потом всегда находил...нужную возможность.
Этот студент был самым успешным.
Он никогда не писал о своих успехах, но жизнь для него была игра, лотерея, в которой он всегда угадывал и всегда достигал цели

Ваша аргументация в пользу СУБД проведена правильно с точки зрения логики, но это КОСВЕННОЕ доказательство. Нет прямых улик и фактов, но они и не нужны, я о них и не спрашивал.

Интересное наблюдение помогает мне, что когда говорят что НЕЗЗЗЯЯЯ кодировку определить, НЕЗЗЗЯЯЯ определить момент закрытия браузера пользователем и т.д., - значит я на верном пути и надо дальше идти.

   
 
 автор: cheops   (12.02.2012 в 16:05)   письмо автору
 
   для: Valleri   (12.02.2012 в 15:54)
 

Нельзя это действительно неправильное слово. Можно, и кодировку можно и момент закрытия браузера можно. Много можно. Нельзя быстро :))) Т.е. мы вот сейчас не бросимся проектировать собственный Web-сервер под ваши нужды, а если бросимся (например, идея понравилась), ждать вам придется года два. А можно практически все. Можно и операционную систему написать, Photoshop, WarCraft, не такое это неподъемное дело, как кажется, времени только много потребуется (в это время нужно что-то есть, т.е. либо не уделять полностью время проекту, что его еще больше затягивает, либо привлекать инвестиции, но тут нужно показать/доказать, как проект окупится в будущем). Т.е. переводить это нужно как "нельзя быстро и бесплатно", а так да, можно :))) Когда будет реализовано, вам скажут, да можно, воспользуйтесь этим программным комплексом выполнив следующие действия или участок кода.

   
 
 автор: Valleri   (12.02.2012 в 16:21)   письмо автору
 
   для: cheops   (12.02.2012 в 16:05)
 

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

   
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования