Vitsliputsli, вы бредите. Не нужно называть словом EAV любое отношение один ко многим. Теги, к которым относится этот вопрос - это, по-вашему, тоже EAV? :)
Судя по всему, вас что-то очень задело, и вы продолжаете спорить просто ради спора.
Это очень сложно сделать без CMS и без углубленных знаний в верстке. А без знания РНР можно даже вообще и не браться.
В форму надо будет добавить очень сложный код. Вот такой <input type="hidden" name="id" value="export">
Да, и в-третьих, в чем вообще смысл ответа, который "задает направление"? Особенно если в нем приводится готовый код. В чем смысл писать код, который заведомо не решает проблему, а только "дает направление", причем весьма неочевидное? Ошибка в логе останется ровно та же самая. И тут даже более-менее прошаренный юзер не враз сообразит "направление". Так что это ваше "если не направит" - на самом деле довольно неприятный снобизм
Эммм, и правда, что-то я обсчитался. А точнее поверил вам на слово, что 72, 24 - это 3 страница. Хотя это на самом деле 4-я.
В общем определитесь сначала, что именно у вас не выводит
ky0, во-первых, я уже написал свой ответ.
Во-вторых, давая другим советы, желательно думать хотя бы на один ход вперёд.
Потому что этот ответ направляет в сторону открыть свою домашнюю папку для пользователя ввв-дата. Нужность этой стороны предлагаю оценить самостоятельно ;-)
Adamos, да не, пиратки как раз используются (чего и боится автор вопроса). Другое дело, что битре без шифрования тупо выгоднее. Расходы на поддержку этих игрулек в бирюльки во много раз превышают убыток от пиратов.
Вы не понимаете, как работает система разрешений в юникс.
Чтобы прочитать файлы из папки /home/dkfire/code/php/dkfire, сначала надо попасть в папку /home/dkfire/code/php. Куда вас никто, разумеется, не пустит.
И как следствие, ошибка вам ничего не будет должна
если вам нужен локальный сервер, то зачем громоздить nginx? Снесите его, запустите php -S dkfire.local:8080 и разрабатывайте себе
А если хотите этжинкс, то и конфигурируйте его нормально, в том числе и в плане размещения
Vitsliputsli, нормализация - это серебряная пуля и панацея. Один из ключевых принципов архитектуры.
И не надо ставить денормализацию на одну доску с ней. Это не принцип проектирования баз данных, а компромисс, который никогда не закладывается исходно, а добавляется сильно позже, когда (если) возникают проблемы с производительностью.
Чем схема плоха, я наглядно показал в своем ответе - при нормальной схеме - когда номер счетчика уходит в условие, где он и должен быть - сразу пропадает ВЕСЬ этот говнокод, и делается простой запрос апдейт.
roswell, та ради бога, пусть сочетаются.
Теги под блог постами тоже сочетаются. Но их никто не пишет в колоночки. Для сочетания и существует связь один ко многим.
Vitsliputsli, он в первом же комментарии это написал, я его процитировал дословно. Но даже и трех колонок уже достаточно, чтобы нормализовать эту самодеятельность. Так что схема однозначно не неплохая.
Vitsliputsli, каким, извиняюсь, местом она "неплохая"? Особенно, "когда там могут быть не только эти три цифры"? Так и будете плодить колоночки с циферками? Вот прям серьёзно?
roswell, это же счетчики, а в SET константы. Тут, как вы и говорили выше, надо нормальную связанную таблицу, и эта циферка станет обычным условием в where
Vitsliputsli, если говорить объективно, то этот код идентичен тому, который написан в вопросе, просто кейс перенесен в SQL.
Если вам лично непривычно использование кейс в запросе, то это не значит, что его вообще никому не следует использовать. Ваш комментарий - это вкусовщина. Кому-то и тернарный оператор нечитабельный.
Другое дело, что эту проблему надо решать не в лоб
Судя по всему, вас что-то очень задело, и вы продолжаете спорить просто ради спора.