Каморка

У вас есть табличка каких-то процессов. Каждым процессом владеет либо user, либо group. Юзеры и группы связаны между собой соотношением много-ко-многим и являются разными обьектами с сильно разным набором свойств. Какой дизайн этого кусочка БД будет самым идеологически выдержанным, по вашему мнению ?

Все зависит конечно от требуемых запросов в большой степени, но как пример:

Таблица Owner содержащая Id и возможно общие между пользователями и группами свойства.
Таблицы User и Group которые ссылаются один-к-одному на Owner по Id.
Таблица Process имеющая атрибут OwnerId

Не являяст спецлм в бд рискну предположить: Редуцировать задачу к задаче, зарплата менеджер работник то есть объеденить группы и пользователей в одной таблице

Я так и знал, что в каморке сидят идеологически выдержанные дизайнеры БД С точки зрения идеологии грамотно будет создать суперкласс "Владелец процесса", от которого некоторые свойства будут наследовать как юзеры, так и группы. Реализация зависит от конкретной БД; в частности, какие-то об'екты можно хранить во VIEW.
Как часто вы видели идеологически выдержанные базы данных ? (рассматриваю таблицу процессов, в которой лежит поле "тип владельца" и "id", которое ссылается либо на юзера, либо на группу в зависимости от значения поля "тип владельца")...

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

Ежели это не нравится - придется заняться сисемным анализом и строить там иерарихии - от юзеров к группам ну и прочая хрень.

А вообще не важно что там выдержано а что нет. Важно - как ты могешь оппонентов которые грят что твой дизайн - фуфло отфутболивать.

это делается элементарно....

создается убер таблица... от нее растут юзеры и группы. релейшеншипы между ИД из убер таблице в третьей таблице.

А я бы сделал так что бы владеть процессом могли только группы.
Не вижу ничего неправильного в том что в группе может быть один юзер.
Зато всё будет логично и прямолинейно...

CREATE TABLE processowner
(
ProcessName VARCHAR(30) NOT NULL,
UserID INTEGER,
GroupID INTEGER,
);

AFAIK nullable FKs is not a problem if PKs in user and group tables have only one field - ID.

DISCLAIMER: I'm not a DBA.

StS писал(а):CREATE TABLE processowner
(
ProcessName VARCHAR(30) NOT NULL,
UserID INTEGER,
GroupID INTEGER,
);

AFAIK nullable FKs is not a problem if PKs in user and group tables have only one field - ID.

DISCLAIMER: I'm not a DBA.

that's a bad design.

Marmot писал(а):А я бы сделал так что бы владеть процессом могли только группы.
Не вижу ничего неправильного в том что в группе может быть один юзер.
Зато всё будет логично и прямолинейно...

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

папа Карло писал(а): that's a bad design.

Why?

папа Карло писал(а):

Marmot писал(а):А я бы сделал так что бы владеть процессом могли только группы.
Не вижу ничего неправильного в том что в группе может быть один юзер.
Зато всё будет логично и прямолинейно...

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

Ууу, докопались таки Да, есть причины, по которым юзер не может быть заменен на группу, состоящую из одного юзера.

StS писал(а):

папа Карло писал(а): that's a bad design.

Why?

Потому что тогда одним запросом не нельзя соединить таблицы процесса и владельца.

папа Карло писал(а): это делается элементарно....
создается убер таблица

А я что предложил?[/quote]

aldep писал(а):

StS писал(а):

папа Карло писал(а): that's a bad design.

Why?

Потому что тогда одним запросом не нельзя соединить таблицы процесса и владельца.

You mean extra roundtrip to the DB from the application? How about this?

CREATE TABLE process
(
ID INTEGER NOT NULL,
ProcessName VARCHAR(30) NOT NULL,
UserID INTEGER,
GroupID INTEGER,
);

CREATE TABLE user
(
ID INTEGER NOT NULL,
name VARCHAR(30) NOT NULL,
);

CREATE TABLE group
(
ID INTEGER NOT NULL,
name VARCHAR(30) NOT NULL,
);

SELECT group.name as name
FROM processowner
INNER JOIN group ON processowner.groupid=group.id
WHERE processowner.id=processID AND processowner.groupid is not null
UNION
SELECT user.name as name
FROM processowner
WHERE processowner.id=processID AND processowner.userid is not null

aldep писал(а):Все зависит конечно от требуемых запросов в большой степени,

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

Впрочем, амбары данных проектируют как раз наоборот - чтоб запросы быстрее были.