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

Question

[Александр]

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

Answer 1

[Алексей Черемисин]

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

Comments

[Александр]

думаю да, до миллиона это точно. Не претендуем на мега популярный сервис.

[Алексей Черемисин]

Александр, п идее там у вас и так получится штук 5-6 таблиц, с логинами, с юсеринфо, с доп-полями типа телефона, с ролями и т.д. И не нужно сыпать все в одну таблицу, расширять проще. Сделайте хотя бы тройку logins, users-info, roles...

Answer 2

[rPman]

Что происходит, когда исполнитель тоже хочет стать слушателем? ему нужно будет новый аккаунт что ли заводить? (некоторые сервисы такой геморой и создают, не позволяя совмещать роли)

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

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

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

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

Comments

[Александр]

хм...вот насчет последнего...насчет функционала пользователей через структуры....да..хорошо что подсказали...Лучше заранее заложить возможности...надо подумать...как вообще это организовать...конечно тут придется использовать ООП...
Можете поподробнее объяснить..Не определять ограничения через структуры..Я просто не программист, но мне нужно разобраться в вопросе, записываю...А как это ограничивать...Через что..Какие виджеты строить..или как это работает..чтобы была возможность добавить или убрать функцию...Тут наверное это через админ панель какую то нужно делать..либо же, сама функция это отдельный код..который будет добавляться через админ панель..или при регистрации...Типо Объект Слушатель..Хм. или вдруг создадим новую роль..это будет легко добавить код..Что то начинает проясняться...интересно!!!

[rPman]

Я просто не программист

не вижу смысла и способа это объяснить.

админ панель это инструмент, который создал программист, и делать может эта панель только то что в нее заложено

да существуют технологи фактического программирования функционала через интерфейс (те же Entity-attribute-value modelкогда простые изменения структуры (добавление новых полей к примеру самое простое) могут быть запрограммированы)