зачем их объединять в одной таблице ?
я имею ввиду, типа базовые данные хранить одном таблице
как минимум с такой структурой у тебя возможно больше мороки с секъюрной частью будет. Дай им роли и все в одной таблице будет.
и точка авторизоваться должен быть единым да?
А что за средство визуализации?
dbdesigner
1. Я бы не стал хранить в БД пароли пользователей. Можно заменить на хранение хэшей 2. Дублируется информация archiveflag, - в трех таблицах, foto_url - в двух, foto_image - в двух. 3. Сегодня лицо является пользователем, а завтра может стать продавцом или послезавтра может вообще доставщик. Это не учтено
я хешом буду хранить паролей) это я чисто для демонстрация сделал
Так и не вынуждайте читателя вашей БД думать про пароли, т.е. почему бы сразу не назвать поле правильно? password_hash ?
Возможно неправ, но я бы сделал так: 1. В таблице Users хранил бы всех. Не важно кто, доставщик, продавец или покупатель это же пользователь. Только у каждого своя специфика. Для всех бы выделил общие сведения. в этой бы таблице и хранил это 2. Затем создал специфично для каждого вида пользователя Customers, Sallers и Delivers . В каждом из которой создал бы поле user_id . И в каждой таблице уже добавил специфичные для этого пользователя вещи 3. Возможно имеет смысл выделить приватную для аутентификации данные в отдельную таблицу AuthUsers Почему так? * Вы действительно не хотите знать номер телефона продавца? Серьезно? * А где сейчас доставщик? Не знаете телефона? Как так? * Информацию связанною с безопасностью желательно хранить отдельно от основной бизнесовой части Вопросы: * А может ли пользователь иметь несколько телефонов? Или прям обязан иметь строго один?
Обсуждают сегодня