Таблица “наследование” в SQL Server
Если я правильно следую логике, на ум приходит exists:
select *
from t1
where exists (select 1
from t2
where t2.id = t1.id and
t2.category in ('Veggie','Fruits') and
t2.date_distributed is null
) or
not exists (select 1
from t2
where t2.id = t1.id and
t2.category in ('Veggie','Fruits')
) ;
РЕДАКТИРОВАТЬ:
Я неправильно прочитал данные из-за первоначального форматирования вопроса. Для вашего вопроса я буду следовать тому же подходу:
select *
from t1
where not exists (select 1
from t2
where t2.t1_id = t1.id and
t2.category in ('Veggie','Fruits') and
t2.date_distributed is not null
) ;
Вы, кажется, хотите t1.id, где они не находятся в указанных категориях с датой распространения.
7 ответов
Я разработал базу данных точно так же, как ссылка, которую Вы предоставили, предлагает. Случай должен был хранить данные для многих различных технических отчетов. Количество типов отчета не определено и вероятно вырастет приблизительно до 40 различных типов.
Я составил одну основную таблицу отчета, которая имеет автоинкрементный первичный ключ. Та таблица содержит всю общую информацию как клиент, testsite, equipmentid, дата и т.д.
Затем у меня есть одна таблица для каждого типа отчета, который содержит определенную информацию, касающуюся того типа отчета. Та таблица имеет тот же первичный ключ как ведущее устройство, и ссылается на ведущее устройство также.
Моя идея для разделения этого в различные таблицы с 1:1 отношение (который обычно был бы нет - нет) состояло в том, чтобы не получать одну единственную таблицу с огромным количеством столбцов, которое становится очень трудным поддержать как Ваши постоянно добавляющие столбцы.
Мой дизайн с наследованием таблицы дал мне сегментированные данные и расширяемость, не будучи трудным поддержать. Единственная вещь, которую я должен был сделать, состояла в том, чтобы записать особенный специальный метод сохранения для обработки записи в две таблицы автоматически. До сих пор я очень доволен дизайном и действительно не нашел недостатков, за исключением немного более сложного метода сохранения.
Google на "спецификации генерала реляционное моделирование". Вы найдете много статей, обсуждающих точно этот шаблон. Некоторые из них фокусируются на дизайне таблицы, в то время как другие фокусируются на объектно-ориентированном подходе.
Наследование таблицы открывается в нескольких из них.
Я знаю, что это не поможет многому теперь, но первоначально, возможно, было лучше иметь таблицу Entity, а не 6 различных типов контакта. Затем каждый Объект мог иметь столько же адресов по мере необходимости и не будет никакой потребности в типе в соединении.
У Вас все еще будет проблема, что, если Вы хотите поля подтипа и у Вас есть только основной контакт, необходимо будет знать что таблица пойти, смотря на - или иначе соединить со всеми ними. Но иначе это - осуществимое решение типичной проблемы.
Другая возможность (довольно подобный в структуре, но отличающийся в том, как Вы думаете о нем) состоит в том, чтобы просто поместить все Ваши контакты в одну таблицу. Затем для более определенных полей (birthday скажите для людей и department для position@company), составляют отдельные таблицы, которые связаны с тем контактом.
Contact Table
--------------
Name
Phone Number
Address Table
-------------
Street / state, etc
ContactId
ContactBirthday Table
--------------
Birthday
ContactId
Departments Table
-----------------
Department
ContactId
Это требует другого образа мыслей вещей, хотя - вместо того, чтобы думать о людях по сравнению с компаниями, Вы думаете о различных функциональных требованиях для задачи под рукой - если Вы хотите отослать поздравительные открытки, получить все контакты, которым связали дни рождения с ними и т.д.
Когда у Вас есть 7-й тип, необходимо будет составить другую таблицу.
Я собираюсь рискнуть здесь и предложить, чтобы Вы заново продумали свою стратегию нормализации (поскольку Вам, кажется, повезло смочь заново продумать Вашу схему вполне существенно). Если Вы обычно храните адрес для каждого контакта, то Ваша таблица контакта должна иметь поля адреса в ней. Кроме того, если адрес хранится на компанию затем, адрес должен быть сохранен в таблице компании и Ваших контактах, связанных с той компанией.
Если Ваши контакты только имеют один адрес или один (или даже 3, просто не 'многие') экземпляр других полей, думайте о рационализации их в единственную таблицу. По моему опыту, наличие нескольких пустых полей является намного лучшей альтернативой, чем оставленная необходимость соединяет с данными, Вы не уверены, существует.
К счастью, для любого, кто сильно не соглашается со мной, Вы действительно просили мнения!:) По моему скромному мнению, необходимо только нормализовать, когда Вы действительно должны. Где Вы заново продумали схемы, денормализацию нужно рассмотреть в каждой возможности.
Я собираюсь попробовать этот подход. Да, вам нужно создавать новые таблицы, когда у вас есть новый тип, но поскольку эта таблица, вероятно, будет иметь разные столбцы, вы все равно будете делать это, если не будете использовать эту схему.
Если таблицы, которые наследуют мастера не сильно отличаются друг от друга, я бы порекомендовал вам попробовать другой подход.