удалять данный старше 1 месяца как-то неправильно. тем более вряд ли у вас данных очень много. и даже 10к записей - это мелочь. бд спокойно справляется с миллионами. главное индексы и кеши. Плюс частота обращений к таким запросам будет редкой.
у меня сбор данных идет в миллионах. и я пока ничего не удаляю, да и не собираюсь, мне нужно анализировать срезы всех данных на каждом промежутке времени, по крайней мере за последнее время. для ТС я дал совет. пусть хранит детализированные данные в отдельной таблице, а агрегированные - в столбце за любой удобный период и никаких проблем не будет
Т.е. когда кол-во просмотров записаных а-ля "id, date" приводится к виду "id, wiews_count, year_month"
можно и не делать вид "id, wiews_count, year_month", а сделать "id, wiews_count". разбивку по прошлым месяцам и годам можно не делать, а просто знать количество общее.
Далее, проходит время. Из таблицы "wiew" удаляются записи старые, подсчитывается их количество и апдейтится вторая таблица, где к количеству просмотров по айди объявления добавляется количество удаленных из первой таблицы. Правильно мыслю?
Т.е. когда кол-во просмотров записаных а-ля "id, date" приводится к виду "id, wiews_count, year_month"
Я думал про то, чтобы записи о просмотрах, имевших место месяц и более назад удалять и где то складировать. Я понимаю так. делаю выборку записей, внесенных месяц назад. Делаю разбивку по "месяц" или "месяц-год". Подсчитываю количество записей по конкретному объявлению за данный период и эту инфу вставляю в таблицу "просмотры-архив".
Далее, для установления количества просмотров объявления и получения временной статистики делаю выборку из таблиц "wiew" и "просмотры-архив", из которых получаю общее количество просмотров. Из первой таблицы получаю статистику по просмотрам в текущем месяце (сегодня, вчера, за неделю, за месяц), а из второй таблицы получаю количесвто просмотров, имевших место свыше месяца назад. Я так понимаю?
Хочу услышать ваше мнение по поводу поднятой мною темы.
Вижу два варианта:
1. В таблице Ads с объявлениями создать столбец view. При просмотре объявления делать UPDATE +1 в столбце view. Недостаток - невозможно разделить, когда эти просмотры были.
2. Создать отдельную таблицу view, в которую при просмотре объявления вносить новую запись с указанием id объявления. Тут можно вносить время просмотра, соответственно, есть возможность разбивки по дням, месяцам и т.д. Этот способ и использую я. Сейчас в БД 7500 объявлений. соответственно, записей в таблице view 780 000. Если объявлений будет 100 000, то записей в таблице просмотров уже будет сколько то миллионов. Понятно, можно добавить индексы к id объявления (для выборки количества просмотров конкретного объявления) и date (для разбивки по времени).
Хочу услышать Ваше мнение об оптимальном решении данного вопроса с учетом указанных перспектив роста количества объявлений.
Мелкий да
Я даже не обратил внимания на регистрозависимость
Наверное потому что оно там неважно alnik-75 снова все верно
Ты решил поиздеваться чтоли?
Я помню ты дофига вопросов задавал ео регуляркам
Походу ты их уже знаешь как никто
Че за фигня иди в пень
Ребята!!!! по сравнению с Вами я вообще никто...... Приятно общаться с Вами...... Мелким. Дип-Варваром (уважаю очень).
Я не специалист в регулярных выражениях, поэтому хочу удостовериться в правильности сделанного
Мне необходимо проверить строку на наличие только строчных латинских букв и цифр. Делаю вот так и вроде бы замечаний нет, но все же, хочу быть уверен в этом:
Спасибо, очень интересно почитать ваши мысли по этому поводу. Я тоже склоняюсь к мнению, что сайт (в данном случае доска объявлений, где нет прямых денежных операций) должен соответствовать требованиям безопасности, но не как не в ущерб удобства пользователя. все вы прекрасно знаете, как лишние меры безопасности нервируют людей. Для них повторность введения пароля-уже проблема.
Почему я создал эту тему? Просто хотел сделать обновление поданных объявлений прямо из рассылки, без лишних телодвижений
Я бы сказал, что проблема не в том, что авторизация сквозная по ссылке. Это дико удобно пользователю и, в сущности, не проблема для многих сайтов - если есть доступ к почте, то восстановить пароль учётки на сайте штатным средством через эту же почту проблемой не является. А вот плохо, что неизвестно, человек ли пойдёт по ссылке или вовсе робот этой же самой почтовой системы.
Некоторое время назад мне весьма надоело, что гугл меня от моей же рассылки отписывает. Как в лучших домах, отписка осуществляется сразу по переходу по ссылке без лишних подтверждений. Потом смотрю в логах, почему мне письма не приходят - меня отписал заход с гугловского ip.
Тогда спрашивается, как "победить" этот робот? Делать отписку, например, с подтверждением?
Если безопасность критична, то привязывать управление подобными операциями к мобильному телефону и желательно со сроком жизни. К примеру если в течении 5-15 минут не будет введен код, то он устаревает. Или через e-mail(если подобная безопасность менее критична), но тоже со сроком жизни. Как видите правила ужесточились, но от дебилов, обычно, никто не застрахован. Можно ещё больше ужесточить подобные процессы, все зависит от критичности и почти всегда есть свои плюсы и минусы.
Спасибо. Я прекрасно понимаю, что может пострадать безопасность.
Добавлю время жизни кода. Что еще можно сделать, чтобы при таких невыгоднях условиях максимально обеспечить безопасность?
А не обязательно что бы злоумышленник сам перевел деньги. Он может со своего аккаунта написать другу Васе, который не подозревает о взломе, что бы Вася перевел деньги на определенный счет. А Вася поверит, потому что это ему Петя написал, его лучший друг!
Можете отправлять ссылки для сквозного входа, вам никто не запрещает, но минусы как бы я вам сказал
Это то все понятно)))) Тогда как, в свете этих проблем, решить вопрос о восстановлении забытого пароля, когда с сайта по почте приходит вновь сгенерированный и измененный в БД для конкретного пользователя пароль? (Добавление)
тут тоже кто-то из-за угла может отвлечь пользователя от компа и зайти вместо него на сайт)))
Денежные операции, я думаю, сильно не пострадают, ведь в любом же случае при переводе, например, вебмани, будет затребована его личная информация.
Я вижу решение своей темы следующим образом.
1. Создаем таблицу с хэш-кодами
2. При осуществлении почтовой рассылки для каждого пользователя формируем хэш-код. Заносим его в таблицу и в тексте рассылки в ссылке указываем его.
3. При переходе по ссылке сверяем хэш-код и id пользователя , указанные в ссылке, с данными в таблице. При совпадение авторизуем пользователя и уничтожаем запись в таблице для того, чтобы исключить повторную авторизацию. В случае если, в таблице нет записи с id этого пользователя или если код не совпадает, то не авторизуем, соответственно.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 339
