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

Question

[Дмитрий Игнатов]

Мне нужно создать приложение для знакомства, и вопрос стал организации струкуры базы данных.
Я могу заполнить некоторые теги о себе, например "Мужчина, некурящий, есть дети и т.д."
Такие же параметры, я могу включить в поиск партнера "Женщина, некурящяя, нет детей и т.д."
Вопрос в следующем, как правильно хранить параметры о себе и параметры того кого хочу найти?
Сохранять данные необходимо для того, чтобы чтобы мне попадались похожие по запросу в ленте.
На данный момент я вижу такую структуру:

id | user_id | gender | option_slug | is_filter

is_filter - нужен для того чтобы понимать, это параметры для фильтрации или это мои параметры

Может у кого то будут идеи получше?

Answer 1

[koder_1]

Колонка is_filter не нужна. У каждого юзера и так хранятся только его параметры.
Если юзер отмечает параметры по которым подбирать ему партнера, то их надо хранить в другой таблице.

Comments

[Дмитрий Игнатов]

То есть две таблицы более правильное решение? Я в начале думал делать две, но потом подумал, что возможно это избыточно будет.

[koder_1]

Естественно нужно 2 таблицы.
Это и более читаемо, в каждой таблице одна сущность, а не 2 разных сущности в одной таблице.
И все запросы будут проще, быстрее и понятнее, не придется возиться с is_filter в каждом запросе.
И с точки зрения производительности скорость запросов и потребление ресурсов зависят от размера таблицы, 2 маленьких таблицы лучше, чем одна большая.
Ну и в целом, у колонки is_filter нет никакой функциональности.

Answer 2

[ThunderCat]

Таблица users - данные о пользователе, + понадобятся справочные таблицы, где у вас будут перечислены свойства (гендер, телосложение, цвета частей тела и прочее).

Таблица prefers - набор желаемых свойств, возможно с диапазонами (типа рост от 150 до 152) или списками (например карие + голубые + зеленые... ) через многие-ко-многим.

Ну и какие-то настроечные/служебные, типа списка избранного, друзей и прочий фуфел.

Answer 3

[pantsarny]

EAV

Answer 4

[mayton2019]

Женщина, некурящяя, нет детей и т.д

В подобного рода заданиях совершенно невозможно сесть и написать ТЗ "от и до".
Здесь практика и эксплуатация будет гораздо важнее всей реляционной теории или шаблонов разработки.
Теория говорит что EAV подходит. Но практически в больших базах EAV не работает потому что он неудобен
и работа с ним идет медленно.

Практика применения DBMS уже отказалась от полной нормализации в классическом виде 3-4-5-6НФ
и уже ей не следуют. Postgresql к примеру позволяет завести JSON поле и туда можно положить
такие сложные атрибуты как

пол = женщиа (феминистика)
статус = вдова
прицеп = 5 детей
курит = нет
любит бухнуть = да но по праздникам
предпочтения в сексе = легкий БДСМ и вынос мозга мужчинам

И эти атрибуты ПРОИНДЕКСИРОВАТЬ (!) средствами Postgres и искать гораздо быстрее чем по EAV.

Возможные аномалии возникающие в следствие денормализации мы можем отдельно обсудить.
Но 99% они решаются не технически а по бизнесу. Просто договариваемся что вот так и так дескыть
переименовать атрибуты мы не можем. Принципиально невозможно но и пофиг. Задача не требует такого.