Каковы методы программного обнаружения взаимосвязей «многие ко многим» в RDMBS? - PullRequest
2 голосов
/ 10 октября 2010

В настоящее время я занят созданием Python ORM, который получает всю свою информацию от RDBMS посредством самоанализа (я бы пошел с XRecord, если бы я был доволен этим в других отношениях) - то есть конечный пользователь только говорит, какие таблицы / views, чтобы посмотреть, и ORM делает все остальное автоматически (если он делает , вы на самом деле что-то пишете, и вы не ищете странных вещей и опасных приключений, это ошибка).

Основная часть этого - обнаружение отношений, при условии, что в базе данных есть все соответствующие ограничения, и у вас вообще нет соглашений об именах - я хочу, чтобы эта ORM работала с базой данных, созданной любым сумасшедшим администратором баз данных, который имеет свои взгляды на то, как должны называться столбцы и таблицы. И я застрял во многих отношениях.

Сначала могут быть составные ключи . Тогда могут быть отношения MTM с тремя или более таблицами . Тогда промежуточная таблица MTM может иметь свои собственные данные , кроме ключей - некоторые данные, общие для всех таблиц, которые она связывает вместе.

Мне нужен метод программного обнаружения, что таблица X является промежуточной таблицей, связывающей таблицы A и B, и что любые неключевые данные, которые она имеет, должны принадлежать как A, так и B (и если я изменяю общий атрибут) изнутри A, это должно повлиять на тот же атрибут в B). Существуют ли общие алгоритмы для этого? Или, по крайней мере, делать предположения, которые являются правильными в 80% случаев (при условии, что администратор базы данных в здравом уме)?

Ответы [ 3 ]

1 голос
/ 11 октября 2010

Если вам нужно спросить, вы не должны этого делать. Я не говорю, что это жестоко, но в Python уже есть несколько отличных ORM, которые хорошо протестированы и широко используются. Например, SQLAlchemy поддерживает атрибут autoload=True при определении таблиц, который позволяет ему читать определение таблицы - включая все, о чем вы спрашиваете - непосредственно из базы данных. Зачем изобретать велосипед, если кто-то другой уже проделал 99,9% работы?

Мой ответ - выбрать Python ORM (например, SQLAlchemy) и добавить к нему любые «недостающие» функции вместо того, чтобы начинать с нуля. Если это окажется хорошей идеей, верните свои изменения в основной проект, чтобы все остальные могли воспользоваться ими. Если это не сработает, как вы надеялись, по крайней мере, вы уже будете использовать обычный ORM, с которым вам могут помочь многие другие программисты.

0 голосов
/ 11 октября 2010

Пока что я вижу только одну технику, охватывающую более двух таблиц. Предполагается, что таблица X связана с таблицей Y, если и только если X ссылается на Y не более, чем на одну таблицу дальше.внешний ключ к Y. Ничего страшного, вот как мы обнаруживаем много-к-одному.

«Одна таблица прочь» означает, что есть таблица Z, которая сама имеет таблицу ссылок на внешний ключ X (их легкоfind) и таблица ссылок на внешний ключ Y.

Это уменьшает объем черт, на которые нужно искать много (нам не нужно заботиться о том, имеет ли промежуточная таблица какие-либо другие атрибуты), и покрывает любыеколичество таблиц, связанных в отношение MTM.

Если есть какие-то интересные ссылки или другие методы, я готов их услышать.

0 голосов
/ 11 октября 2010

Теоретически, любая таблица с несколькими внешними ключами по сути является отношением «многие ко многим», что делает ваш вопрос тривиальным.Я подозреваю, что вам нужна эвристика того, когда использовать шаблоны MTM (а не стандартные классы) в модели object .В этом случае изучите ограничения выбранных вами шаблонов.

Например, вы можете смоделировать простое отношение MTM (две таблицы, без атрибутов), используя списки в качестве атрибутов для обоих типов объектов.Однако списков будет недостаточно, если у вас есть дополнительные данные о самих отношениях.Так что вызывайте этот шаблон только для таблиц с двумя столбцами, оба с внешними ключами.

...