users (id, login, type, type_id)
user_type_fizlic (id, fname)
user_type_urlic (id, fname, lname, inn)
user_type_root (id, root_key)
type указывает на таблицу ее типа например type может быть равен "fizlic"
type_id указывает на id в этой таблице типа
Фактически есть таблицы разных типов пользователей под общим id
Я вижу этот способ не слишком удобным. На то чтобы получить полные
данные юзера приходится делать минимум два запроса, и join тут не
помошник, т.к. всеравно придется сначала узнать тип юзера
Спустя 3 минуты, 36 секунд (11.03.2011 - 10:51) Семён написал(а):
Достаточно сделать 2-ве таблицы users, groups и плясать уже от них.
Спустя 10 минут (11.03.2011 - 11:01) xdeviloper написал(а):
Семён, можно подробней...
смысл ведь в том, чтобы гдето хранить дополнительные данные пользователей а самих пользователей держать под общим id
смысл ведь в том, чтобы гдето хранить дополнительные данные пользователей а самих пользователей держать под общим id
Спустя 9 минут, 3 секунды (11.03.2011 - 11:11) Семён написал(а):
Я хз какие у тебя там зависимости, планы на расширяемость полей и параметров, на вскидку я бы делал так.
---
Если динамически уникальные опции и значения:
Данные пользователя вроде имени, фамилии, email или id группы хранишь в users
Джойнишь таблицу groups по id группы из users, у группы соответственно параметры какие-то группы и т.д.
Джойнишь таблицу options по id из users.
Расставляешь индексы, получаешь выборку пользователя с группой и набором параметров у него.
---
Если фиксировано делаешь всё оставь как есть, за исключением того, что не нужно дублировать имена пользователя в других таблицах.
---
Если динамически уникальные опции и значения:
Данные пользователя вроде имени, фамилии, email или id группы хранишь в users
Джойнишь таблицу groups по id группы из users, у группы соответственно параметры какие-то группы и т.д.
Джойнишь таблицу options по id из users.
Расставляешь индексы, получаешь выборку пользователя с группой и набором параметров у него.
---
Если фиксировано делаешь всё оставь как есть, за исключением того, что не нужно дублировать имена пользователя в других таблицах.
Спустя 3 минуты, 35 секунд (11.03.2011 - 11:14) xdeviloper написал(а):
вариант понятен, скажи, а индексы ты бы как расставил учитывая, что сортируемой может быть любая колонка, и в users и в типовой таблице
Спустя 3 минуты, 48 секунд (11.03.2011 - 11:18) Snus написал(а):
xdeviloper
Делай 3 таблицы
Получится у тебя нечто вроде
И естественно id везде PRIMARY KEY + автоинкремент.
а userId - UNIQUE KEY
Делай 3 таблицы
users (id, log, typeId) - юзвери
user_param (id, userId, fname, lname, inn) - параметры юзверя
user_type(id, name) - таблица с типами Юр.лицо или Физ.лицо
SELECT u.log, t.name AS `type`, p.fname, p.lname, p.inn
FROM `users` AS `u`
INNER JOIN `user_type` AS `t` ON t.id = u.typeId
LEFT JOIN `user_param` AS `p` ON p.userId = u.id
Получится у тебя нечто вроде
log | type | fname | lname | inn
Вася | Юр.лицо | бла-бла | бла-бла | 1234567890
Петя | Физ.лицо| NULL | NULL | NULL
И естественно id везде PRIMARY KEY + автоинкремент.
а userId - UNIQUE KEY
Спустя 11 минут, 10 секунд (11.03.2011 - 11:29) xdeviloper написал(а):
Snus, Интересный вариант, спасибо
Спустя 3 часа, 56 минут, 33 секунды (11.03.2011 - 15:26) Trianon написал(а):
Если сущность юрлица кардинально отличается от сущности физлица (а я предполагаю это весьма вероятным), то делать для их свойств общую таблицу может оказаться крайне неудобно.
Я бы в таблице users оставил два чужих ключа (на каждую из таблиц со специфическими свойствами), пометив их как NULL, и вытаскивал специфичные данные через два LEFT JOIN.
Я бы в таблице users оставил два чужих ключа (на каждую из таблиц со специфическими свойствами), пометив их как NULL, и вытаскивал специфичные данные через два LEFT JOIN.