Как спроектировать базу данных сайта знакомств на MySQL?

Question

[CodeInside]

Пишу сайт знакомств, используя СУБД MySQL. Bот думаю над такими вещами:
1) в анкете пользователь выбирает одну с 9-ти стран. В таблицу их лучше вносить через enum или делать нормализацию?
2) стоит ли делать поля "имя", "фамилия", "дата рождения" ключами для использования B-tree индексов? (эту тему я плохо понял)
3) в книге Шварца и т.д. "оптимизация производительности mysql" прочёл, что лучше избегать значений NULL и если нету информации - заменять её пустой строкой. Каким образом это осуществить? Просто в поле "Значение по умолчанию" ничего не писать и оно автоматически будет заполняться пустой строкой?
4) и если делать нормализацию, то лучше использовать подсистему хранения Memory?
PS: планируется высокое посещение сайта (десятки тысяч пользователей).

Answer 1

[index0h]

1. ENUM вообще говоря довольно большая штука 65535 вариантов. Но все же рекомендую делать через нормализацию, вам это словарь может еще пригодится где-то.
2. Ключами стоит делать то, по чем вы будете искать. В случае, если данные в конце слабо отличаются, а основные изменения в начале - имеет смысл ограничить индекс по размеру (ВНИМАНИЕ ТОЛЬКО ДЛЯ ЭКОНОМИИ ПАМЯТИ). Например:
abcd
bacd
dxdc
aabd
У приведенных строк на последнем символе разница не существенная, посему индекс можно ограничить 3-мя.
3. Вот тут бабка на двое гадала, если у вас будет индекс на уникальность (НЕ primary), то множество NULL вы получить сможете, а вот множество "" - нет. NOT NULL рекомендую использовать в случае, если вы требуете обязательности заполнения данных.
4. Конечно MEMORY! Всего один сбой в ДЦ и у вас появится работы на еще пол года, это же замечательно)) В памяти можно хранить только то, что вы согласны в любой момент потерять.
Если по хорошему - memory таблицы во первых имеют кучу ограничений, во вторых - проигрывают k-v хранилищам типа memcached/redis по скорости, в третьих не поддерживают вытеснения.

PS: планируется высокое посещение сайта (десятки тысяч пользователей).

За какой период?
Если за сутки - это... не высокое посещение, вы даже foreign ключики позволить себе сможете.
Если за минуту (и реально много данных) - вот это уже интересно, про FK забудьте, пересчет индексов будет слишком дорогим. Под поиск - смотрите в сторону кластера на elasticsearch, так же скорее всего потребуется кластер мемкэшей. БД дергать можно будет но по минимуму. Основная работа должна будет происходить в фоновом режиме, посему подберите сервер очередей типа rabbitmq, или что-то типа того.

Answer 2

[Валерий Рябошапко]

1. Если Вы точно уверены, что количество стран не выйдет за десятку, то можно и ENUM, но всё же лучше нормализовать и сделать отдельную таблицу с индексом. Ведь для выборки текстового представления ENUM СУБД полезет в файл и будет там искать его простым перебором. На десятке стран это не критично, но при росте вызовет лаги. Кстати, это один из тех немногих случаев, когда в primary key можно спокойно выбирать тип данных TINYINT :-)
   
2. Большинство систем хранения MySQL умеют только B+-tree индексы, так что заморачиваться с выбором между B- и B+-деревьями не стоит, надо просто решить, нужен ли индекс вообще. Для этого нужно знать архитектуру всего приложения. В общих чертах можно описать так, что если по полю будет производиться поиск, то индекс нужен. Не думаю, что кого-то на сайте знакомств будут искать по фамилии (разве что по имени в целях "совместимости"). По дате, скорее всего, тоже будет просто сортировка
   
3. Прямо совсем и всегда избегать NULL не стоит. Многие советуют обходиться без него, поскольку для его обработки MySQL использует лишний байт памяти и несколько лишних тактов процессорного времени. Определиться довольно просто: если предполагается, что поле может быть пустым, то NULL лучше оставить и не городить костыли. Если же поле обязано быть заполненным, то лучше написать NOT NULL и задать значение по умолчанию. То есть, например, поле "имя" можно смело писать NOT NULL, а вот для поля "любимая книга" можно и оставить NULL, далеко не все посетители сайтов знакомств дружат с литературой.
   
4. Вопрос странный. Нормализация - это приём построения баз данных, позволяющий избавиться от дублирования данных, избежать ошибок. Это промышленный стандарт, можно сказать. Какую подсистему хранения выбрать - зависит уже от свойств хранимых данных. Вообще удобнее InnoDB, так как она поддерживает внешние ключи. Но можно использовать и Memory для чего-то чувствительного к скорости, но нечувствительного к потере.
   

Answer 3

[Игорь]

1) Немасштабируемое решение! Все страны нужно вынести в отдельную таблицу.
2) Зависит от конечных запросов. Сделайте сначала без индексов, потом проанализируйте запросы. Без полного архитектурного представления нельзя сказать, какие индексы потребуются ))
3) Верно! Если не знаете с какой целью данное поле должно быть NULL, то делайте тип поля NOT NULL.

Каким образом это осуществить?

А каким образом Вы создаете базу данных?
4) Не понял вопроса

Comments

[CodeInside]

3) через phpMyAdmin
4) если вынести список стран в отдельную таблицу, то какую для неё выбрать подсистему хранения данных?

[Игорь]

CodeInside:
3) в phpMyAdmin делать поля NOT NULL при создании таблицы (не ставить чекбокс NULL)
4) По поводу подсистемы: MEMORY юзают для хранения оперативных данных в ОЗУ! Т.е. это энергозависимая память, при рестарте сервера данные будут утеряны!
Обычно выбирают между MyISAM и InnoDB в пользу InnoDB из-за поддержки транзакций хотя бы.

Answer 4

[Максим Гречушников]

1. справочник стран. в анкете хранить ид страны. связь "многие к 1"
2. хз что такое бтрее индексы.
3. лучше использовать нулл. наверное не так поняли тему или был какой то нюанс.
4. иннодб