мне кажется, если запись происходит чаще, чем чтение, то такой подход будет быстрее. Но если к объекту применить сотню записей и миллион чтений, то подход из статьи будет быстрее.
об этом уже несколько раз обсудили в комментах вокруг. Имхо, такой пароль близок к ССЗБ.
И большей проблемой будет не наличие/отсутствие пробелов, а наличие нескольких валидных паролей.
так делать не стоит, потому как тогда появится два валидных пароля. Даже не два, а целая куча паролей, которые отличаются от пользовательского, но которые система считает за правильные. Как уже тут указали, нужно с самого начала об этом думать, и сразу тримить пароль, и при регистрации, и при входе. А так как обычно ставят нижнюю границу длины пароля (хотя бы 4-6 символа, я думаю, нужно ставить всегда), то пароль из одних пробелов, или где пробелы имеют существенную часть пароля, просто не пройдут ещё при регистрации.
да ладно. Пусть будет мой ответ для других.
К тому же, у вас не глупость. Я вот тоже хочу так писать — WHERE tag IN (:includedTags) AND tag NOT IN (:excludedTags). Возможно, получится разработать такую структуру таблицы tag_links, чтобы такой запрос сработал (что вряд ли), или составить запрос по другому, например, через самопересечение этой таблицы.
так не получится — SELECT вначале отбирает записи, и только потом группирует и сортирует их. А так как в записи только одно поле tag, то NOT IN точно не сработает, потому что после первого условия там записи с полем tag из первого списка.
В этом комментарии я больше говорил про личные записи. В частности, в Evernote в заметках я указываю 2-3 тега-рубрики (работа, проект, 2014) и пяток тегов, относящихся конкретно к этой заметке. После этого очень удобно их искать, и проблема тега «покрытие» из статьи исчезает, достаточно указать фильтры проект+игры или развлечение+игры, и найдутся разные заметки.
А сайт, на котором я использовал систему тегов, я вам в личку отправил.
>нужно дать режим оптимизированно скомпилировать программу так, чтобы она вычисляла именно то, что желает вычислить программист. shadr1.ru/button/button.html
м-м-м… да, простите. Верно, tag_links.tag — идентификатор тега, tag_links.id — это идентификатор статьи.
1, 2, 3 — айдишники искомых тегов. Их может быть и больше трёх.
Всего три таблицы — articles, tags и tag_links, реализующая связь многие-ко-многим первых двух таблиц.
Таблица articles: id, title, body
Таблица tags: id, name
Таблица tag_links: id, tag
Я обычно ставлю много тегов, с тем, чтобы потом можно было просматривать связанные статьи. Добавление 2-3 тегов не даёт практически ничего, нужно ставить десяток тегов.
Но это плохо работает, если нет механизма поиска по нескольким тегам. Даже больше, если этого механизма нет, то теги сильно уступают рубрикам. В принципе, в статье об этом и написано…
У меня есть алгоритм вывода статей по тегам именно так — задаются три тега, и вначале выводятся все статьи со всеми тремя совпадающими, потом выводятся все статьи с совпавшими любыми двумя тегами, и потом уже выводятся все статьи, в которых один из представленных тегов. Причём делает это за один SQL-запрос.
Вариант для поиска номеров статей:
SELECT id, count(*) as weight FROM tag_links
WHERE tag IN (1,2,3) GROUP BY id ORDER BY weight DESC
Вариант для вывода списка статей:
SELECT articles.id, articles.title FROM tag_links, articles
WHERE tag_links.id=articles.id AND tag_links.tag IN (1,2,3)
GROUP BY tag_links.id ORDER BY count(*) DESC
Если интересно, могу написать статью про то, как шёл к этому решению. Ничего выдающегося, в общем-то, но боюсь, здесь в комменте это затеряется…
Добавьте уведомления для моих ответов. Сейчас, если я хочу увидеть комментарии к моим ответам, то мне приходится подписываться на весь вопрос, а другие ответы мне не всегда интересны. Также хорошо бы получать уведомления на те ответы, в которые я написал комментарий.
Если мой ответ выбрали решением, то я не получаю уведомление об этом, если я не подписан на вопрос. Это не удобно.
Добавьте в список моих ответов в профиле галочку «Решение». Так же хорошо бы отмечать вопросы с моими ответами в виджете «Популярные вопросы» (хотя вопросы, где я уже был, браузер выделяет отдельным цветом, так что это не так важно).
И большей проблемой будет не наличие/отсутствие пробелов, а наличие нескольких валидных паролей.
К тому же, у вас не глупость. Я вот тоже хочу так писать — WHERE tag IN (:includedTags) AND tag NOT IN (:excludedTags). Возможно, получится разработать такую структуру таблицы tag_links, чтобы такой запрос сработал (что вряд ли), или составить запрос по другому, например, через самопересечение этой таблицы.
А сайт, на котором я использовал систему тегов, я вам в личку отправил.
shadr1.ru/button/button.html
1, 2, 3 — айдишники искомых тегов. Их может быть и больше трёх.
Таблица articles: id, title, body
Таблица tags: id, name
Таблица tag_links: id, tag
Но это плохо работает, если нет механизма поиска по нескольким тегам. Даже больше, если этого механизма нет, то теги сильно уступают рубрикам. В принципе, в статье об этом и написано…
Вариант для поиска номеров статей:
Вариант для вывода списка статей:
Если интересно, могу написать статью про то, как шёл к этому решению. Ничего выдающегося, в общем-то, но боюсь, здесь в комменте это затеряется…
Если мой ответ выбрали решением, то я не получаю уведомление об этом, если я не подписан на вопрос. Это не удобно.
Добавьте в список моих ответов в профиле галочку «Решение». Так же хорошо бы отмечать вопросы с моими ответами в виджете «Популярные вопросы» (хотя вопросы, где я уже был, браузер выделяет отдельным цветом, так что это не так важно).