MySQL выборка, что быстрее?

Question

[enigma2030]

Добрый день. Уважаемые гуру MySQL, проконсультируейте пожалуйста. Возник спорный вопрос как лучше хранить данные для оптимальной выборки.
Дано. Таблица пользователей.
Необходимо. Реализовать рассылку по SMS.
Вариант 1. В таблице с пользователями хранить признак того что пользователь может получать SMS.
Вариант 2. Создать дополнительную таблицу, в которой будут храниться пользователи которые могут получать SMS.
Во первых, что правильнее в плане архитектуры, а во вторых насколько медленнее будет работать выборка при втором варианте.

Comments

[Слава Витренко]

Сколько записей будет храниться в таблице всех пользователей?

[enigma2030]

Слава Витренко: Ориентировочно назвать тяжело, но размер со временем должен быть приличный.

[Слава Витренко]

Ну хватит стесняться, назовите примерно - тысяча, десять, сто?..
Почему спрашиваю - при взаимодействии с отправителем смс у него обычно бывают лимиты (по разному, от 1000 до 1000000 записей за один запрос).
Какой лимит у вас? Имхо, скорее всего затык будет здесь, а не при выборке из бд.

[Слава Витренко]

Например, у сервиса, которым пользуемся мы, цитирую:
"Скорость рассылки - более 2000 SMS в минуту". Это в на порядок меньше, чем мы можем выбрать из бд в секунду

Answer 1

[Rsa97]

А смысл выделять свойство сущности в отдельную таблицу? Конечно же хранить в основной.

Comments

[enigma2030]

Благодарю за ответ. Ну к примеру потом надо будет добавить еще признак привязки подписки на email или еще как-нибудь расширить сущность пользователя. Для этого нам придется менять структуру таблицы. А так мы не меняя основную таблицу через связь можем расширять сущность пользователя. Как быть в данной ситуации?

[Rsa97]

enigma2030: А в чём проблема изменить структуру таблицы? Если все запросы к ней делаются с указанием списка полей, а не *, то никто этого и не заметит.
Второй вариант, если собираетесь делать множество вариантов подписки, то есть смысл создавать таблицу не под именно SMS, а под подписки в целом (user_id, send_method, send_to). Тогда пользователь сможет создать себе неограниченное количество подписок на разные адреса/телефоны.

[enigma2030]

Благодарю! Примерно к такому рассуждению самостоятельно и пришли, что второй вариант будет лучше если будет N - количество способов рассылки и чтобы не "замусоривать" таблицу с пользователями то разумнее все вынести в другую таблицу. Тут мы скорее получаем "архитектурный" выигрыш от того что у нас все будет более логично структурировано, а так же мы будет придерживать правил нормализации.
Но проигрываем в производительности выборки. Правильно ли я рассудил?

[Rsa97]

enigma2030: Выборка чего? Выбирать все методы рассылки каждый раз смысла нет. Они нужны в двух местах - в управлении списком конкретного пользователя, где идёт выборка небольшого списка по конкретному user_id, и в самой рассылке, где скорость выборки не критична.
Если каждый раз делать JOIN то да, будет медленнее.

Answer 2

[Vit]

Зачем вам дополнительная таблица? Что это даст?
Заведите флажок в таблице юзеров и индекс на него.

Comments

[enigma2030]

Благодарю за ответ. Вот тут как раз и "размышления" что нам может дать вынос этой связи в отдельную таблицу, правильнее ли это со стороны построения архитектуры базы данных, в какой ситуации такой вариант имел бы преимущество.

Answer 3

[Антон Агальцов]

Смотря какую выборку вы делаете.

В первом варианте, если у вас признак отмечен как индекс, то работать будет достаточно быстро.
С вторым вариантом у вас возникнет проблема с изменением данных, точней не проблемы, а накладные расходы.

Если у вас единая выборка по рассылки "всем пользователям у кого стоит отметка" то оба варианта будут работать приблизительно одинаково. Если вы делаете выборку по группам пользователей, а потом выборку по признаку отправки смс, то вариант первый должен быть быстрей, так как задействована одна таблица.

Comments

[enigma2030]

Благодарю за ответ. Получается лучше "расширять" таблицу с пользователя, вводя новые поля для расширения сущности пользователя?

[Антон Агальцов]

enigma2030: Это и удобней и практичней. Вы можете ограничивать выборку с помощь Select col1, col2... и получать из БД не все данные по пользователю, а только то что нужно вам.

Но опять же, все должно быть в рамках разума.

Answer 4

[Alex]

А Я вот не сторонник тянуть такие флаги в основную таблицу....
Взяли новую, со связью 1 к 1 или 1 ко многим.
Перестраивать архитектуру таблицы ради галочки.... А потом их будет 100, 1000
Да и места занимать будет меньше. ИМХО

Comments

[Растишка]

ну будет 100 галочек - не проблема, когда будет 1000 (а будет ли?) сделать рефакторинг.
А в вашем случае мне придется джойнить 1000 таблиц по ключу????

[enigma2030]

Илья Зенин: В принципе на этой почве и появились разногласия. Вносить ли флаг привязки в основную таблицу с пользователями или выносить всю связь в отдельную таблицу. По сути не хотелось бы "засорять" таблицу пользователя, скажем так "свойствами", которые не присущи самому пользователю как сущности. Лучше вынести это в отдельную таблицу и там сохранять все эти связи, что я полагаю и имел ввиду пользователь Alex. Но данный вариант будет более рационален если будет реализовываться функционал описанный пользователем Rsa97 , т.е. при множественном варианте различных способов рассылки. По сути тогда нам надо будет всего лишь отфильтровать эту таблицу по необходимому типу рассылки, получить массив ID пользователь и потом уже на основании него сделать выборку из таблицы пользователей. А так в принципе есть это поле будет одно то наверное нет смысле выносить все в отдельную таблицу.