Таблица супертипов без (идентифицирующих) уникальных свойств

Question

В приложении, которое я разрабатываю, происходит время от времени, когда требуется шаблон SuperType/SubType. Моя проблема обычно возникает, когда применяется эксклюзивная специализация подтипов. Эксклюзивность специализации сама по себе может быть легко реализована на уровне языка программирования, поэтому использование шаблона является тривиальной задачей. Однако иногда супер тип не имеет идентификационных свойств (столбцов) от себя - кроме идентификатора, который присутствует в каждой создаваемой таблице. Фактическая идентификация указана в каждой таблице подтипов. По идентификации, я имею в виду комбинацию столбцов с уникальными значениями, например:

• В countries столе name
• В provinces столе country_id + name
• В car_wheels столе car_id + wheel_position

Я узнал, что практически каждая таблица содержит идентифицирующие столбцы.

В моем конкретном случае, у меня есть следующие таблицы:

documents 
----------------------------- 
id | publicly_accessible 

webpage_documents 
---------------------------------------------------------- 
id | document_id | name (as well as certain other properties, too) 

ajax_script_documents 
----------------------------- 
id | document_id | name 

pdf_documents 
----------------------------- 

etc... 

Там существуют Relation таблицы, которые ссылаются на documents и Подтип каждого документа в потенциально получил целую систему суб для своих собственных. Следовательно, шаблон SuperType/SubType.

Как вы можете видеть, таблица documents содержит булевский столбец publicly_accessible, который, очевидно, не является идентифицирующим столбцом. Существуют также ситуации, когда даже такая колонка отсутствует. Это означает, что таблица супер-типа содержит только столбец id, который для меня не только пахнет, но и запутывается при просмотре его содержимого.

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

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

Answer 1

Я бы подумал о таблице DocumentType. Эта новая таблица знает имя и дополнительную информацию о типе (общее место хранения, приложение для просмотра, ...)

Вы можете либо оставить свой супер-стол и поместить этот новый идентификатор (с помощью FK) в таблицы с расширением doc , или вы держите свой супер-стол и размещаете его там ...

Wether doc общедоступно может быть значением уровня doc-типа или значением уровня doc. Я предпочитаю каскад значений в таких сценариях: может быть ваш логический столбец с NOT NULL как часть таблицы типа doc и другой столбец с нулевым значением на уровне документа (либо в супер таблице, либо в таблице распространения). Вы принимаете это значение, если NOT NULL и возвращаетесь к умолчанию, установленному в вашем doc-типе ...

Супер таблица полезна, если вы используете общую информацию, такую ​​как автор, время создания, статус, последнее редактирование, без разницы...

Answer 2

Привет, я добавлю еще один ответ, так как это будет много для комментария, и я не хочу убирать первый.

Ну, я думаю, что вы смешивать некоторые понятия:

Ваш пример со странами, провинций или car_wheels являются «вложенными компонентами». В основном они связаны 1: n (1 страна, много провинций, 1 автомобиль, многие [а, возможно, 4] колеса). Иногда возникает особая ситуация 1: 1 (1 автомобиль имеет 1 двигатель), но это не по определению, а по правилу. You может думать о машине с двумя двигателями (например, от аккумулятора и аккумулятора). Это НЕ наследование (супер тип [базовый класс], тип и подклассы). Вложенный тип не будет соответствовать правилу «есть». Провинция не является страной, колесо не является автомобилем ...

Наследование всегда 1: 1. Подтип (в вашем случае - специальный документ) - документ.

В таком случае у вас есть дерево видов данных:

1. Общие данные (в вашем случае это будет DocId, имя, автора и информацию о состоянии и DOCTYPE (или как FK к боковой стол или автономный)
2. Переопределяемые данные: Тип супер или один из его боковых таблиц определяет значение по умолчанию, и специальная строка doc может отменить это значение (в вашем случае, вероятно, что-то о правах, доступности ...)
3. Специализированные данные: Данные, которые относятся к специализированному типу, но не ко всем типам документов

Обычно вы должны использовать VIEWS для каждого специализированного типа документа, чтобы доставлять составные данные супер-типа, а производные - вести себя так, как если бы это была таблица. С SQL Server вы можете определить такие VIEWS с привязкой к схеме, с индексами и ограничениями.

С вашего вопроса мне было не совсем ясно, что вы не хотите менять основную концепцию. Нет проблем, придерживайтесь таблицы doc, но подумайте о следующем: вам действительно нужны специализированные таблицы для разных типов документов? В вашем единственном примере во всех случаях указано «имя», что является довольно общей информацией, которая должна быть в супер таблице. Какая польза? Какая информация настолько уникальна для PDF, DOC, HTML, что необходимы несколько разных таблиц?

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

Удачи в поиске лучшей и подходящей концепции!