Смешивание отношений владения и ссылок в базах данных - PullRequest
Новая
       38

Смешивание отношений владения и ссылок в базах данных

0 голосов
/ 15 января 2012

Я давно использую XML и иерархические базы данных, где легко определить владельца.Сейчас я пробую модель реляционной базы данных, в которой у меня есть контекст времени выполнения, в который я загружаю сущности с уникальными идентификаторами и реляционными свойствами, такими как ProductId и т. Д.

Мой вопрос заключается в том, как я собираюсь добавить некоторыевид собственности на эту модель?Если я хочу определить отношения, где целевой объект является родительским владельцем объекта.Как я могу определить это различие для ссылочного отношения и сохранить его в базе данных SQL с минимальной дополнительной информацией?Есть ли какая-либо поддержка в SQL (MS) для определения типа отношений?

В конце концов, я хочу иметь возможность выяснить, какие другие сущности удаляются, когда удаляется какая-то другая сущность (все принадлежащиелица).Также при сериализации этой сущности в XML я хочу сериализовать ссылочные сущности как обычные id-элементы и принадлежащие сущности с полным XML. 

<Notebook Id="1">
  <LibraryId>5</LibraryId> <!-- Referenced entity -->
  <AuthorId>6</AuthorId> <!-- Referenced entity -->
  <Notes> <!-- Owned entities -->
    <Note Id="2" />
    <Note Id="3" />
    <Note Id="4" />
  </Notes>
</Notebook>

Сущность Note обычно хранится отдельно от Notebook в своем собственном SQL-таблица с колонкой NotebookId.Но как мне определить этот столбец как принадлежащие отношения?Я думаю, я мог бы назвать его OwnerId или OwningNotebookId и просто проанализировать имя столбца.Но я надеялся на лучший метод.Что вы предлагаете?

1 Ответ

1 голос
/ 15 января 2012

Основное различие заключается в том, что ссылка хранится на стороне «Многие» ссылки «Один ко многим».

Для библиотеки и автора ссылка находится в таблице «Блокнот», поскольку каждая библиотека и автор могутЕсть много книг заметок.

Для заметок ссылка на таблицу заметок по той же причине.

Пример схемы ниже показывает ссылки. 

CREATE TABLE Author
(
    id int primary key,
    name varchar(100)
);

CREATE TABLE Library
(
    id int primary key,
    name varchar(100)
);

CREATE TABLE Notebook
(
    id int primary key,
    libraryid int not null references Library(id),
    authorid int not null references Author(id)
);

CREATE TABLE Note
(
    id int primary key,
    notebookId int not null references Notebook(id)
                               on delete cascade,
    note  varchar(100)
);

Связь между Заметкой и Записной книжкой имеет опцию «Каскад при удалении», что означает, что если Записная книжка удалена, Заметка также автоматически удаляется из базы данных.

Параметр по умолчанию «on delete restrict» будет препятствовать удалению родительской строки, пока существует дочерняя строка.

Если NotebookId не равен NULL, это означает, что заметка не может быть создана безсоответствующая записная книжка, поэтому жизненный цикл заметок всегда связан с родителем.

...