и структура работает как положено +1

идея, как я могу связать разные объекты вместе? Вариант использования, которого я пытаюсь достичь, - это комментарии, которыми обычно владеет пользователь. Так что у меня есть user_id для этого. Но у меня есть и страницы компании, где компания владеет контентом на своей странице, поэтому ее владельцем является company_id. (Какой из них является администратором нескольких пользователей)

Один из способов состоит в том, чтобы иметь 2 таблицы user_comments и company_comments, но проблема в том, что мне нужно 2 таблицы на объект, и если я добавляю больше типов пользователей, мне нужно несколько таблиц. То, что я хочу достичь, это 1 таблица, которая имеет:

comment_id PK  
owner_id (user id or company id or etc...)  - fk?

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

Ответы на вопрос(1)

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

Чтобы реализовать это в базе данных SQL, поместите столбцы, общие для людей и организаций, в одну таблицу, называемую, например, «Стороны». Колонки, уникальные для людей, идут в таблице людей; столбцы, уникальные для организаций, входят в таблицу организаций. Используйте представления, по одному на каждый подтип, чтобы скрыть детали реализации; Ваши клиенты используют представления, а не таблицы.

В качестве владельца ваших комментариев вы бы использовали ключ из таблицы супертипов "Стороны". (Думаю.)

Вот упрощенный пример.

create table parties (
    party_id integer not null unique,
    party_type char(1) not null check (party_type in ('I', 'O')),
    party_name varchar(10) not null unique,
    primary key (party_id, party_type)
);

insert into parties values (1,'I', 'Mike');
insert into parties values (2,'I', 'Sherry');
insert into parties values (3,'O', 'Vandelay');

-- For "persons", a Subtype of "parties"
create table pers (
    party_id integer not null unique,
    party_type char(1) not null default 'I' check (party_type = 'I'),
    height_inches integer not null check (height_inches between 24 and 108),
    primary key (party_id),
    foreign key (party_id, party_type) references parties (party_id, party_type)
);

insert into pers values (1, 'I', 72);
insert into pers values (2, 'I', 60);

-- For "organizations", a subtype of "parties"
create table org (
    party_id integer not null unique,
    party_type CHAR(1) not null default 'O' check (party_type = 'O'),
    ein CHAR(10), -- In US, federal Employer Identification Number
    primary key (party_id),
    foreign key (party_id, party_type) references parties (party_id, party_type)
);

insert into org values (3, 'O', '00-0000000');

create view people as
select t1.party_id, t1.party_name, t2.height_inches
from parties t1
inner join pers t2 on (t1.party_id = t2.party_id);

create view organizations as 
select t1.party_id, t1.party_name, t2.ein
from parties t1
inner join org t2 on (t1.party_id = t2.party_id);

Сделайте представление обновляемым, используя любую функцию, которую предоставляет вам dbms. (Вероятно, срабатывает.) Затем код приложения можно просто вставить в соответствующее представление.

 aneroid13 дек. 2012 г., 08:18
"(Существует уникальное ограничение для party.party_id.)«Да, извините, пропустил это. Так что запрос не требуетparty_type и структура работает как положено +1
 aneroid11 дек. 2012 г., 09:43
+1 Мне нравится иметь избыточное «фиксированное значение»party_type столбцы вpers а такжеorgs, вы можете обеспечить целостность FK (вместо того, чтобы простоparties.party_id в качестве основного, который позволит дублироватьparty_idвpers а такжеorgs - так как, безparty_type, все равно будет разрешено в определении данных). Проблема в том,parties Таблица по-прежнему позволяет (4, 'I', 'x') и (4, 'O', 'y') существовать, поэтому избыточностьparty_type остается необходимым. Таким образом, запросы должны включатьparty_type, Однако, если ПК был толькоid и ограничение былоuniq(id,type) тогда хорошо
 Mike Sherrill 'Cat Recall'11 дек. 2012 г., 12:56
«Проблема в том, что таблица сторон по-прежнему допускает (4,« I »,« x ») и (4,« O »,« y »)»Нет, это не так. Попробуй. (Существует уникальное ограничение для party.party_id.) Столбец "party_type" необходим для преодоления недостатка в SQL. Реляционная модель не требует этого, и SQL dbms, который поддерживаетCREATE ASSERTION не требует этого Но нет никаких SQL dbms, которые поддерживают утверждения.

Ваш ответ на вопрос