@Bob89991

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

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

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

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

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

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

для любой современной СУБД это очень маленький обьём данных
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
agoalofalife
@agoalofalife
Full stack разработчик
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(заключение договоров, ведение переговор с сохранением данных об этом и так далее) то есть процесс не мгновенный из одного состояние в другое, то наверное надо хранить в другой таблице.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы