PHP - лучший способ регистрировать активность пользователей и отображать их на разных страницах? - PullRequest
Новая
       23

PHP - лучший способ регистрировать активность пользователей и отображать их на разных страницах?

1 голос
/ 25 сентября 2010

Я зарегистрировал активность пользователя на своем веб-сайте в файл .txt. Я хочу, чтобы эти результаты отображались в моей административной области на отдельных страницах. Итак, на первой странице показано 1-50 результатов и т. Д.

Но у меня проблема в том, что она изложена в файле .txt

User: Admin IP Address: xx.xxx.xxx.xx Host Address: xxxxxxxxxxxxxxxx Date And Time: Monday 20th of September 2010 11:44:18 AM URL: <a href="http://colemansystems.psm2.co.uk/" rel="nofollow">http://colemansystems.psm2.co.uk/</a> Browser: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.62 Safari/534.3 Refering URL:

С пропуском в семь строк между каждым набором информации. Я думал о том, чтобы поместить его в таблицу MySQL, но со временем это не станет слишком большим?

Любая помощь приветствуется!

Ответы [ 3 ]

4 голосов
/ 25 сентября 2010

Так что, если он станет большим?Вот для чего нужны базы данных.

Позвольте мне заверить вас, что [единовременная] стоимость настройки базы данных и таблицы будет намного меньше, чем поддержание файла данных доморощенного (как в пользовательском формате) вв долгосрочной перспективе.

Что если вы хотите узнать, что произошло между 2010-09-25 и -26 по IP-адресу 1.2.3.4?Собираетесь ли вы написать функцию?(Это единственный оператор в SQL.) Собираетесь ли вы сканировать весь файл?(Надлежащие СУБД будут использовать только индексы. MySQL будет использовать хотя бы один индекс.)

Я наполовину склонен сказать «попробуй их обоих и посмотри, как подход с БД выиграет в долгосрочной перспективе», потому что преимуществаслишком много, чтобы перечислить.

0 голосов
/ 25 сентября 2010

Любая современная база данных, включая MySQL, будет обрабатывать запросы к правильно проиндексированной таблице за разумное время с несколькими десятками миллионов строк в ней.Это то, что они для .

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

0 голосов
/ 25 сентября 2010

Таблица базы данных кажется более подходящей для этого, если вы будете запрашивать ее, а не просто просматривать журналы в каком-то мониторе (например, в хвосте Unix).

Со временем оно станет очень большим, поэтому вы можете его сократить, время от времени удаляя старые записи, если заметите снижение производительности. Вы можете установить скрипт, который запускает запрос DELETE к таблице для всех записей старше, скажем, 1 месяца. Затем вы можете запланировать выполнение этого сценария ежедневно.

Другим вариантом будет использование разбиения по дате, если вам действительно нужны все журналы, даже более старые, но это немного сложнее.

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

...