А
Size: a a a
2020 March 04
SP
зависит от того что у них отличается. я бы хранил отдельно креды, отдельно профили (если они у всех одинаковые), и отдельно все остальное. То есть на три типа юзеров у меня (возможно) было бы 5 таблиц
SP
опять же - решение бы я принимал в связке с тем, как разные типы пользователей влияют, че у них разного и зачем они нужны в принципе. есть есть различия - лучше разделить. Склеивать чуть проще
А
зависит от того что у них отличается. я бы хранил отдельно креды, отдельно профили (если они у всех одинаковые), и отдельно все остальное. То есть на три типа юзеров у меня (возможно) было бы 5 таблиц
Общего у них только мыло, пароль, да ещё пара служебных полей
КГ
Пытаюсь смоделировать систему с различными типа пользователей и различными типами профилей для каждого типа пользователей. Варианта вижу два:
—
—
и
—
—
—
User (email, password) → Person (name, address) + SubProfileA (...) | SubProfileB (...)—
User (email, password) → Company (title, address) + SubProfileC (...) | SubProfileD (...)и
—
Person (email, password, name, address) + SubProfileA (...) | SubProfileB (...)—
Company (email, password, title, address) + SubProfileC (...) | SubProfileD (...)Я делал так, пользователь один. В нём только связь к кредам для авторизации и роли (роли по сути только в админке работают).
Дальше есть профили. Профиль покупателя/продавца и тд. Эти профили имеют связь на юзера
Дальше есть профили. Профиль покупателя/продавца и тд. Эти профили имеют связь на юзера
Р
Я делал так, пользователь один. В нём только связь к кредам для авторизации и роли (роли по сути только в админке работают).
Дальше есть профили. Профиль покупателя/продавца и тд. Эти профили имеют связь на юзера
Дальше есть профили. Профиль покупателя/продавца и тд. Эти профили имеют связь на юзера
Делаю аналогично, связь вообще не обязательно
Р
Еси uuid генерить, можно и по where in искать
КГ
А uuid это не связь?
КГ
Или связь это обязательно relation в ORM и констрейнт в базе?
А
Я делал так, пользователь один. В нём только связь к кредам для авторизации и роли (роли по сути только в админке работают).
Дальше есть профили. Профиль покупателя/продавца и тд. Эти профили имеют связь на юзера
Дальше есть профили. Профиль покупателя/продавца и тд. Эти профили имеют связь на юзера
Я тоже так делал, но тут вот чот призадумался
Р
Или связь это обязательно relation в ORM и констрейнт в базе?
Логично, думал именно про референс кей
КГ
Я тоже так делал, но тут вот чот призадумался
Почему? Есть проблемы?
МГ
всем добра и пряников.
такой вопрос
на продакшен сервере постоянно слетает авторизация.
буквально час и все.
на тестовых все нормально
код отвечающий за запуск сессии вот
@session_set_cookie_params(15555555);
@session_start ();
что можно посмотреть еще?
такой вопрос
на продакшен сервере постоянно слетает авторизация.
буквально час и все.
на тестовых все нормально
код отвечающий за запуск сессии вот
@session_set_cookie_params(15555555);
@session_start ();
что можно посмотреть еще?
А
Почему? Есть проблемы?
ТЗ недописано, есть смущающие моменты типа «у организации может быть 3 пользователя» — понимай как хочешь
КГ
ТЗ недописано, есть смущающие моменты типа «у организации может быть 3 пользователя» — понимай как хочешь
Ну так есть пользователь, есть организация. А есть какой OrganizationUser
КГ
OrganizationUser - тут профиль с инфой относительно огранизации. Например должность, доступы к этой организации и тд
А
Ну так есть пользователь, есть организация. А есть какой OrganizationUser
Или нет OrganizationUser и это придумка, о которой уже забыли — ТЗ невнятное. Просят начать работу хоть как-то, потому что полимеры частично просраны