Что такое хорошая практика при настройке таблицы пользователей? Глядя на некоторые новички, но не уверен, как «действительно» сделать это правильно

Question

Я занимаюсь созданием API-интерфейса для отдыха, который подключается к базе данных. Я следую учебным пособиям, но настройки таблиц на самом деле являются основными, и одна из моих проблем заключалась в том, что в «реальном мире» способ его выполнения намного сложнее и разнообразнее :(

Однако, м интересно для моего фактического применения (очень маленький), как я могу правильно настроить в User таблицу?

Например, я поставил первичный ключ userid, потому что никогда не должно меняться. это нормально использовать long для userid?

Кроме того, хорошо ли объединить кучу вещей, связанных с пользователем .. в таблице пользователей? Я знаю его глупый вопрос .. Например, Я хочу знать, зарегистрирован ли пользователь для этой услуги, поэтому isMember. Или, пользователь зарегистрировался для быстрого обслуживания, поэтому hasFastService. Или, если эти вещи будут помещены в таблицу UserAttributes с помощью идентификатора пользователя?

Наконец, я посмотрел UUID, и я задаюсь вопросом, где те подходят, в которых сценарии и т.д.

Благодаря

Answer 1

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

1. Аутентификация: Определите процесс регистрации и такие вещи, как верительное поле, типы пользователей (администратор/гостевой/нормальный), требуется ли OAuth или нет, и т.д. перед созданием таблицы users. Например, нужно ли вам имя пользователя/пароль для аутентификации или электронной почты/пароля или «имя пользователя или адрес электронной почты» с паролем. Современная практика заключается в том, чтобы покончить с «именем пользователя» с момента ее избыточности - электронное письмо уникально и действует как имя пользователя для всех целей.
2. OAuth: Если вы даете логины facebook/google/twitter, сделайте резерв для этого в таблице своих пользователей. Как вы определяете, является ли пользователь обычной подпиской или социальной регистрацией? Поле, такое как «login_method» или что-то полезное в этом отношении. Может быть создано второе поле под названием «user_type» для идентификации типа учетной записи пользователя: admin/guest/employee/etc.
3. Профильные поля: Его до вас для определения переменных профиля. В моем последнем проекте я использовал несколько полей типа FirstName, LastName, Theme, Timezone и т. Д. Для профиля, но ваш пробег может отличаться.

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

Излишне говорить, что никогда не храните фактический пароль в поле пароля. Просто имеет свой пароль и сохранит его. Когда пользователь входит в систему, вы можете хэш-вход пользователя и сравнивать его с табличным значением пользователя.

И, наконец, НЕ путайте таблицу пользователей, включая связанные данные, такие как клиенты, сотрудники и т. Д. Все клиенты - это пользователи, но все пользователи не являются клиентами! Держите ваш дизайн гибким, чтобы включать всех пользователей, таких как администраторы, сотрудники и т. Д.