Информационная схема SQL — чтение внешних ключей COMPOSITE

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

Одна из вещей, с которыми я столкнулся, - это внешние ключи, в частности - КОМПОЗИТНЫЕ внешние ключи с одним ограничением. Например, если у меня есть следующие таблицы:

Компания

CompanyID, CompanyName, CompanyID
--companyID is the primary key which identifies the company. 

Отдел

DivisionID, CompanyID, DivisionName, DivisionID+CompanyID
--DivisionID+CompanyID is a composite primary key for a division, because it's a one-to-many relationship and division is DEPENDENT on Company. 

Команда

TeamID, DivisionID, CompanyID, TeamName, TeamID+DivisionID+CompanyID
--same as above - a Team is dependent on Division, which has a composite primary key.

Итак, эта модель базы данных — по всем определениям — действующая модель (и SQL Server это допускает), но я столкнулся с определенной проблемой.

Например, в информационной схеме как DivisionID, так и CompanyID «присваиваются» одному и тому же ОГРАНИЧЕНИЮ. Итак, когда я присоединяюсь к нужным столам, у меня возникает проблема. Невозможно узнать, какой столбец в одной таблице является каким столбцом в другой. В приведенном выше примере имена столбцов одинаковы (CompanyID — это имя каждого столбца, связанного с идентификатором компании — будь то в таблице COMPANY, таблице TEAM и т. д.), но нет правила, которое говорит, что имена столбцов должны быть одинаковыми, поэтому я не понимаю, как на самом деле заставить программу узнать, какой столбец какой.

TABLE1    COLUMN1        CONSTRAINT         TABLE2     COLUMN2
TEAM      CompID      TEAM_HAS_DIVISION    DIVISION   CompanyID
TEAM      DivID       TEAM_HAS_DIVISION    DIVISION   DivisionID

Есть ли способ узнать, что CompID в таблице TEAM ссылается на CompanyID, а не на DivisionID в таблице DIVISION?

Я не смог найти способ сделать это из данных в представлениях INFORMATION_SCHEMA.

Да, человек может легко понять, что CompID = CompanyID и т. д., но, как я уже упоминал ранее, я пытаюсь создать общее решение, которое не требует, чтобы человек смотрел на это и принимал решения и совершал ошибки := )


person Iv4n    schedule 13.04.2011    source источник


Ответы (1)


Вы должны сопоставить их по порядку столбцов.

  • REFERENTIAL_CONSTRAINTS сообщает вам, что ограничение TEAM_HAS_DIVISION имеет PK_Division в качестве основного ключа.
  • KEY_COLUMN_USAGE говорит вам, что TEAM_HAS_DIVISION имеет DivID и CompID в том порядке, который указан в столбце ORDINAL_POSITION.
  • KEY_COLUMN_USAGE также сообщает вам, что PK_Division имеет DivisionID и CompanyID в том порядке, который указан в столбце ORDINAL_POSITION.

Вот как вы узнаете, какой из них относится к какому.

person Andrew Savinykh    schedule 14.04.2011
comment
Спасибо за ответ, я думал о порядке (ordinal_position), но я не был уверен, что на этот счет тоже есть какие-то гарантии. Например, что мешает разработчику БД расположить столбцы в одной таблице в обратном порядке? ИЛИ требует ли сервер, чтобы порядок составных ключей был определенным? - person Iv4n; 14.04.2011
comment
Попробуй сам. Вы можете размещать столбцы в первичном ключе в любом порядке, но вы не можете создать внешний ключ со столбцами в другом порядке, чем в первичном ключе, на который вы ссылаетесь. - person Andrew Savinykh; 14.04.2011
comment
Спасибо ZSEPRI, я только что увидел, что ORDINAL_POSITION в таблицах KEY относится к позиции внутри ключа, а не в таблице. Таким образом, даже если они «вверх ногами» в таблице, они правильно расположены в тональности. Большое спасибо!! :) - person Iv4n; 14.04.2011