Какой подход к проектированию бд более оптимален?

Question

[Bob89991]

Какой подход в перспективе более выигрышен, например есть таблицы "contacts" и "users". Пусть они имеют +/- одинаковый набор полей. contacts - это users, которые пока не оплатили услугу и не могут аутентифицироваться на сайте. После оплаты контакт конвертируется в юзера.

Я считаю что данный подход не оптимален и лучше сделать какой-то флаг в таблице "users" типа "status_id" и сразу добавлять клиентов в эту таблицу. А при аутентификации просто проверять email, password и status_id. Но я не знаю, как поведет себя данная модель при достижении порога в 100к+ юзеров.

Вся суть вопроса вкратце: что лучше, быстрее etc иметь 2 практически идентичные таблицы или одну, но использовать какой-нибудь status_id (индексовый, само собой) для выборки? При условии, что в базе сотни тысяч записей.

Answer 1

[deepblack]

что лучше, быстрее etc иметь 2 практически идентичные таблицы или одну, но использовать какой-нибудь status_id (индексовый, само собой) для выборки

В данном случае лучше одну

При условии, что в базе сотни тысяч записей.

для любой современной СУБД это очень маленький обьём данных

Comments

[Bob89991]

> В данном случае лучше одну
А можно пример, когда лучше две, пожалуйста?

[deepblack]

Bob89991, только когда данные в них логически никак не связаны, но это и так очевидно ))
Еще вариант: когда делают откровенную х**ню

Answer 2

[Кирилл Горелов]

Это то что ты ищешь Жамки

Answer 3

[Илья Чубаров]

But I also knew, and forgot, Hoare's dictum that premature optimization is the root of all evil in programming

Надо ответить себе на несколько вопросов:
- Имеет ли такую нужду(как оптимизация) база данных место быть. У вас есть уже такой трафик?Если да, тогда и правда стоит подумать об этом
- Надо думать и о доменной(бизнес модели), если в бизнесе такое понятие как contacts или он был придуман вами. Когнитивная нагрузка будет возрастать если например в вашем бизнесе это называют потенциальный заказчик(например). Заходя в структуру базы, без документации, не будет очевидно копирование из таблицы contacts to users.
- Таблица contacts - это денормализация данных, частая практика для экономии операции чтения, насколько здесь оправдано - не ясно, так как задача вырвана из общего контекста(любое условие или перспектива будущего могут на него повлиять). Если вам надо просто различать состояние user, то вы можете сделать пометку в этой таблице. Если у вас есть дополнительная работа с candidate user(заключение договоров, ведение переговор с сохранением данных об этом и так далее) то есть процесс не мгновенный из одного состояние в другое, то наверное надо хранить в другой таблице.

Не знаю в каком у вас состоянии находиться проект, на мой взгляд заострять внимание на производительности базы не приоритетный шаг в самом начале.✌️