рализовать то возможно, но удобство использования просто ад будет. Во 1-ых тег может склонятся. Бывает такое ага. Во вторых контролировать количество тегов на выводе будет просто нереально. Т.е. к примеру ты захочешь сделать страницу с тегами. Как будешь реализовывать ее? Постоянно шарить по базе вытаскивая все разные теги? Далее, чтобы вытащить все посты с каким-то тегом, то надо будет чтобы все эти теги были в индексе, а это дофига лишней потребляемой памяти таблицей.
я как та девченка - "вся в сомнениях" ;D
С одной стороны получаем одну большую таблицу, с другой несколько "маленьких" Но опять же, если надо будет добавить еще какую нибудь сущность для лайков? А как вообще люди проектируют такие вещи?
тогда уж в каком-нибудь мемкеше держать ключ что-то типа lastvisits:user_id(или ип), с expire = необходимое время слежения. До 00.00 следющего дня или сутки ровно. Проверять просто его наличие.
ну, поиск по маске на данный момент используется исключительно чтобы удалить группу ключей. для поста например какого-то конкретного, если произошли изменения и при этом кешируется не вся страница а частично блоками.
Теги... Да это типа неймспейсов. Нагуглил когда искал Memcashed tags.
ну, перед тем как начать использовать редис проштудировал всевозможные бенчмарки. Редис из коробки судя по ним все же быстрее. Но это далеко не основной критерий выбора. А что касается "можно и редисом". Можно то можно, вопрос - правильно ли?
в целом согласен, однако подготовленные выражения в моем случае использовать никак. Для этого необходимо будет переписать полностью класс для работы с бд. Клиенту этого не требуется, а инициативу проявлять я не намерен ;D
В данном случае вставить что-либо сложно, поскольку допустимы только числа, отличные от нуля в большую сторону.
Меня больше интересует такая свзязь через подзапрос. Может лучше было бы сначала селектом проверить наличие фотки в альбоме + возможнные разрешения, а только потом удалять.
Тут тоже момент есть. Все ли старые телефоны поддерживают данную технологию? Старые - это которые с первой оперой мини на борту. Например на самсунге Х100 (да да, не смейтесь, задача стоит в том числе, чтобы показывалось и на этом =) )
о мобильном шаблоне, скорее так. Который на том же домене с абсолютно теми же урлами, но показывается в зависимости от устройства пользователя (либо по его принудительным настройкам)
Не совсем. Гугл настоятельно рекомендует облегчать мобильные версии сайта, иначе будут проблемы с мобильной выдачей. Отсюда и пляски. Первичный пользователь идет именно с поисковика. Так что игнорировать этот момент глупо.
Насколько я понял, автор одиночка. Поэтому все что ниже касается первопроходцев одиночек, и исключительно ИМХО.
Изучение всего этого потребует колоссального времени, которое, вполне возможно, будет потрачено впустую. Поэтому на начальных этапах не стоит заморачиваться с программированием бэкенда, а стоить изучить какую-нибудь цмс и запустить долгожданный проект. Если он понравится людям, то уже потом начать изучать и переписывать под собственные нужды и задачи. Или же вовсе отдать на аутсорс. Ну а если не не интересно будет людям, то хрен с ним, можно следующий запускать гораздо быстрее чем первый.
bl1nder: на самом деле так и есть. Проект на пхп, на данный момент используется уже глубоко переработанная цмс дле(архитектура осталась старая). Когда стартовал еще особо не разбился в тонкостях веб технологий и работал на интерес, но сайт выстрелил и приходится пахать на том что есть. Тем более что сейчас это основной источник дохода. Посещалка хорошая но далеко не хайлоад, так что цмс справляется. Однако внедрение нового функционала становится ооочень проблемным, да и в целом обслуживание кода очень удручает.
Штука вот в чем. С одной стороны действительно хочется просто все взять и переписать заново, с учетом текущих трендов. Однако надо поддерживать старый код + дополнять всякими плюшками(в лучших традициях говнокода), что очень много вермени отнимает и жутко деморализует.