Проблема с запросом записи

Question

У меня есть коллекция геообъектов в базе данных:

Есть четыре таблицы:

Countries
Regions
Provinces
Cities

Города имеют, в частности, код провинции Провинции имеют, в частности, регионКод Регионы имеют, в частности, CountryCode

И есть пятая таблица: описания

ObjectCode
ObjectType(country, region, province, city)
Description.

Как получить из таблицы описаний все описания объектов, которые находятся в определенной стране ??

Answer 1

Убирая мыльницу, вот актуальное решение:

select Countries.code as  country_code  
       , count_d.description as country_desc
       , Regions.code as  region_code  
       , reg_d.description as region_desc
       , Provinces.code as  province_code  
       , prov_d.description as province_desc
       , Cities.code as  city_code  
       , city_d.description as city_desc
from  Countries
        join Descriptions count_d
             on ( count_d.ObjectCode  = Countries.code
                  and count_d.ObjectType = 'COUNTRY' )
        join Regions
             on ( Regions.CountryCode = Countries.code )
        join Descriptions reg_d
             on ( region_d.ObjectCode  = Regions.code
                  and count_d.ObjectType = 'REGION' )
        join Provinces
             on ( Provinces.RegionCode  = Regions.code )
        join Descriptions prov_d
             on ( prov_d.ObjectCode  = Provinces.code
                  and count_d.ObjectType = 'PROVINCE' )
        join Cities
             on ( Cities.ProvinceCode  = Provinces.code )
        join Descriptions city_d
             on ( city_d.ObjectCode  = Cities.code
                  and count_d.ObjectType = 'CITY' )
where Countries.whatever = 'DONDESTAHN'
/

На самом деле не проверено, так что следите за опечатками! Они представляют собой особую опасность с помощью Cut'N'Paste Driven Development.

Answer 2

Я подозреваю, что @zerkms будет не единственным, кто не понимает, что не так с этой моделью данных, поэтому стоит изучить ее недостатки.

1.Он не имеет реляционной целостности

Первичный ключ описаний предположительно (ObjectCode, ObjectType).Это не сопоставляется ни с одним родительским ключом, поэтому нет способа применить правило, согласно которому описание должно принадлежать какому-либо объекту.Даже если ObjectCode уникален для всех таблиц (скажем, это сгенерированный UUID), так что первичным ключом описаний может быть (ObjectCode), мы все равно не сможем применить ограничение внешнего ключа, поскольку один дочерний ключ не может ссылаться на несколько родительских ключей.

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

@ Предложение EoinCampbell о переводе модели в шестую нормальную форму - Страны CountryDescriptionРегионы RegionDescription и т. Д. - по крайней мере обладает достоинством поддержки целостности данных.

2.Производительность пострадает

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

Опять же, 6NF имеет преимущество, поскольку оно будет масштабироваться лучше, чем опубликованная реализация.

3.Слишком много таблиц

Новое требование: нам нужно держать ABBREVIATION для всех этих объектов.Это не атрибут Description, поэтому мы не можем сохранить его в этой таблице.Но мы не можем поставить столбец «Население» в поле «Страны, регионы и т. Д.», Поскольку было бы несовместимым .Итак, нам нужна еще одна таблица сокращений.Да, и пользователи хотели бы также провести НАСЕЛЕНИЕ.И ОБЛАСТЬ, если не возражаешь.Прежде чем вы это знаете, select * from countries стал объединением в пять столов.

Вот где 6NF ломается.Количество необходимых таблиц быстро метастазирует в схему ошеломляющих пропорций.

Вот почему самые разумные люди останавливаются в BCNF, или, по крайней мере, в 3NF.

Answer 3

Я могу видеть, как мой DBA съеживается, если он читает это ... Если опция ре-факторинга / нормализации является опцией, я бы либо

a) Поместите столбец описания в каждую таблицу ... ИЛИ ЖЕ б) Создайте отдельные таблицы для описаний для каждого объекта ... т.е.

Страны CountryDescriptions районы RegionDescription и т.д ...

Если это не вариант

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

CREATE VIEW vCountryDescriptions
AS 
SELECT * FROM Countries c 
JOIN Descriptions d ON c.ObjectCode = d.ObjectCode 
AND d.ObjectType = 'Country'

Повторите для каждой сущности.

А потом объедините свои 4 вида вместе.