- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Уважаемые знатоки MySQL!
Допустим, есть таблица комментариев. И в ней поле E-mail, при этом поле, естественно, может повторяться, т.к. один пользователь может оставить несколько комментариев. В админке нужно выводить список всех E-mail. Так вот есть два способа решения:
1) отдельная таблица emails с UNIQUE email, туда добавляется E-mail каждый раз при написании нового комментария, как INSERT IGNORE.
2) SELECT DISTINCT email FROM comments, при этом у email есть индекс INDEX.
Что быстрее? Будет ли MySQL-сервер при запросе SELECT DISTINCT email считывать просто все подряд из индекса или будет перебирать всю таблицу?
Спасибо!
По заповедям тексты не должны повторяться. Зачем инсерт игноре - инсерт и дубликате ки убдате
Зачем отдельная таблица если данные будут выводиться только в админке.
Да и не в админке тоже.
SELECT DISTINCT и все
или GROUP BY
Админка тут временно. Позже ТС может захотеть сделать рассылку по этим адресам, или банить по адресу, или продать их кому-нить на спам, или порыться через них в социале и собрать все досье.
Следовательно нужна каноничная таблица users с той лишь разницей что поле passw может быть null. Автоматическое добавление юзера по введенному имейлу делается через тот самый запрос. Прицепить такую таблицу к каментам по user_id еще более каноничная и тривиальная задача.
Ну то есть обычная юзерская схема, только вся гостевая, или не вся, а только тех, у кого пассв - нул.
если что, это был гипотетический вопрос, никакой таблицы комментариев и емейлов нет:)я мог вместо E-mail придумать любое другое поле. Вопрос именно в скорости работы SELECT DISTINCT и выборки из отдельной таблицы.
если что, это был гипотетический вопрос, никакой таблицы комментариев и емейлов нет:)я мог вместо E-mail придумать любое другое поле. Вопрос именно в скорости работы SELECT DISTINCT и выборки из отдельной таблицы.
Если так, то SELECT email FROM быстрее чем SELECT DISTINCT email FROM, при стандартных настройках и архитектуре СУБД.
Конечно же SELECT без DISTINCT быстрее SELECT c DISTINCT :)
Вопрос именно в скорости работы SELECT DISTINCT и выборки из отдельной таблицы.
Нет, вопрос именно в парадигме. Или вы заполняете базу хламом и потом разгребаете его в рабочем порядке как программисты делают, или вы заполняете базу фактами и оперируете их отношениями как делают инженеры БД.
Уважаемые знатоки MySQL!
Допустим, есть таблица комментариев. И в ней поле E-mail, при этом поле, естественно, может повторяться, т.к. один пользователь может оставить несколько комментариев. В админке нужно выводить список всех E-mail. Так вот есть два способа решения:
1) отдельная таблица emails с UNIQUE email, туда добавляется E-mail каждый раз при написании нового комментария, как INSERT IGNORE.
2) SELECT DISTINCT email FROM comments, при этом у email есть индекс INDEX.
Что быстрее? Будет ли MySQL-сервер при запросе SELECT DISTINCT email считывать просто все подряд из индекса или будет перебирать всю таблицу?
Спасибо!
Разницы в скорости не будет, будет считывать все из индекса.
---------- Добавлено 03.08.2015 в 23:13 ----------
Нет, вопрос именно в парадигме. Или вы заполняете базу хламом и потом разгребаете его в рабочем порядке как программисты делают, или вы заполняете базу фактами и оперируете их отношениями как делают инженеры БД.
Программист и напишет "использовать нормализацию", как будто бы это надстройка, а не базис.