Как грамотно сформировать БД пользователей?

Стоит задача: разработка веб - сервиса. Музыкальная тема.
Это будет веб - сайт, мобильное приложение и приложение для smart tv. Точнее это такой интерфейс для запросов к серверу.
Вопрос, при регистрации идет выбор "слушатель" или "исполнитель". У каждой из этих групп будет как общий функционал( такие как поиск, добавить в плейлист .. .. ) так и личный, например слушатель не может загружать на сервис музыку, видео - клипы.
Так вот. Правильно ли будет создать две таблицы в базе данных пользователи: Таблица Слушатели и таблица Исполнители.? Или всех пользователей записывать в одну таблицу( мне кажется это менее производительно)
И второе. Можно ли сделать так. Например разделить пользователей на таблицы с id. например id от 0 до 100000, с id 100001 в другую таблицу. И при входе или поиске пользователя ускорить поиск. Например если id > 100000, но меньше 200000, искать в таблице 1. иначе в таблице 2. Такая вот идея. Опишите пожалуйста свои мысли. Снизит ли это нагрузку на сервер? Ускорит ли это работу сервиса.
Пока что собираю лучшие решения и идеи заранее, а честно говоря не знаю с какой стороны подступиться к проекту.
Конечно на данном этапе проще нарисовать дизайн, но я не понимаю, как начать писать сервер..с таким функционалом..
Или хотя - бы родить какой никакой MVP проекта.
  • Вопрос задан
  • 127 просмотров
Пригласить эксперта
Ответы на вопрос 3
Vamp
@Vamp
Делить пользователей по разным таблицам имеет смысл только если набор колонок для них будет кардинально отличаться.

На начальном этапе задумываться о производительности не стоит. Вы все равно не угадаете какое место в будущем станет бутылочным горлышком производительности.

Создавайте свой веб-сервис с расчетом на удобство сопровождения. А когда начнутся проблемы с производительностью - тогда и будете уже предметно разбираться с конкретной проблемой.
Ответ написан
Комментировать
leahch
@leahch
Я мастер на все руки, я козлик Элек Мэк :-)
Сколько всего пользователей планируется? До миллиона вообще без разницы - одна таблица, а после уже смотреть по нагрузке. Да и думаю, что проблема будет совсем не с таблицами пользователей, поверьте. Это самые ненагруженные таблицы и запросы, если правильно подойти к авторизации и аутентификации, например на тикетах.
Ответ написан
@rPman
Что происходит, когда исполнитель тоже хочет стать слушателем? ему нужно будет новый аккаунт что ли заводить? (некоторые сервисы такой геморой и создают, не позволяя совмещать роли)

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

Поэтому у тебя должна быть таблица peoples и связи к ней musicans и listeners

Совет, постарайся избегать ситуаций, когда в идентификаторах нужно что то упаковывать, какую то информацию, в битах как у тебя. Это накладывает кучу ограничений потом по оптимизации (например шардинг по нескольким серверам) или лимитирует количество, ведь заранее не угадаешь лимиты. Не экономь на полях, есть нужная к использованию информация - добавляй поле или даже целую таблицу

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

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

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