Поиск ссылок на запись в таблице

[YaHooka]

Вопрос следующий: Есть произвольная таблица. Есть конкрентая запись в этой таблице. Можно как-нибудь построить список всех объектов системы, ссылающихся на эту конкретную запись? Т.е. что-то аналогичное Запрос-Сыылки в плане счетов или кнопке "Ссылки" в сериях документов.

Возможно ли в принципе построить такой список?

[mazzy]

можно. но сложно.

ссылаться может тремя способами:
1. на уникальный ключ (ключей может быть несколько, ключи могут быть составными)
2. на recid (который может отсутствовать, кстати)
3. на другую компанию (тогда надо искать пары dataAreaId + ключи и dataAreaId + recId)

В общем, в других таблицах надо рассматривать все возможные комбинации уникальных ключей. Что в общем случае будет долго. А сам алгоритм достаточно нетривиальным.

Кстати, а задача очень красивая.

[mazzy]

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

[YaHooka]

Думается мне, что задачка такая в общем случае не реализуема. Могут же быть в системе таблицы, логчиески связанные, но при этом не связанные физически. Просто лукап написали.

[mazzy]

Не понял.
Думаю, что задача реализуема.

[YaHooka]

Я и сам не понял, к чему это я
Имел в виду, что технически возможна следующая ситуация:
Есть таблица A {код, название}, сделали таблицу B {код, название, код записи из таблицы A}. При этом тип поля "код записи из таблицы A" сделали текстовой (или число там). Не использовали EDT, не настраивали Relations, в общем не дали Аксапте понять что таблицы связаны. А для пользователя сделали лукап, чтобы пользователь как бы выбирал данные из таблицы А. Получается таблицы не связаны физически, а связаны логикой работы.

Хотя пожалуй в таких тяжелых ситуациях уже ничто не спасет.

Интересно, встречаются ли такие ситуации в стандартной аксапте?

[glibs]

Цитата:

Изначально опубликовано YaHooka
...
Интересно, встречаются ли такие ситуации в стандартной аксапте?
...

А как же!

Например, в строках заказа можно найти строчки, у которых в полях InventRefType, InventRefId и InventRefTransId будут заполнены координаты заказа. Такое может случиться, если по заказу-контракту создать заказ на отпуск. Если контракт, например, после этого переименовать, то случится маленькая неприятность.

Думаю, что аналогичные места в системе еще есть.

[AndyD]

2 mazzy

2. Если RecID отсутствует, то тут и ссылаться не на что. Вообще, по-моему, случай с RecID самый сложный, так как приводит к необходимости проверять все таблицы, где используется тип recId или его наследники. Да и индекса по этому полю может не быть.

3. Этот пункт вообще не понял. Либо dataAreaId входит в состав уникального индекса, либо нет. Или имеется в виду, что в поле может быть ссылка на виртуальную компанию?


По моему алгоритм поиска будет выглядеть следующим образом:

1. Вытаскиваем из AOT информацию по уникальным индексам этой таблицы и наличию поля recId.

2. Ищем информацию по типам полей, входящих в индексы.

3 Ищем наследников этих типов, проверяем, было ли изменение релейшенов в них (перенаправление на другую таблицу), если было, то отбрасываем.

4. Ищем наследников EDT recId, если это поле есть в таблице. Возможно в наследниках определены релейшены, что облегчит поик по таблицам и сузит круг исследуемых типов.

5. Проверяем все таблицы на наличие в них полей, входящих в индексы (по типам полей, полученных в пп. 2 и 3). Если хотя бы одно поле из индекса не входит в таблицу, то этот индекс не рассматриваем.

6. Параллельно с п. 5 проверяем релейшены на таблицах, возможную ссылку на исследуемую таблицу.

7. Параллельно с пп. 5 и 6 проверяем, есть ли в таблице поля, имеющие типы, полученные в п. 4, кроме собственного поля recId этой таблицы.

8. Для ускорения собственно поиска рассматриваем существующие индексы на таблицах, вхождение отсеянных в пп. 5-7 полей в эти индексы. Предпочтение отдаем индексам в которых эти поля входят в порядке, указанном в уникальном индексе.

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


Дальше идет собственно сам поиск по полученным в пп. 5-7 таблицам с использованием индексов, полученных в п. 8. Если эта строка принадлежит виртуальной компании, то необходима будет проверять по всем компаниям, входящим в виртуальную.

В общем так. Я ничего не забыл?

[mazzy]

Цитата:

Изначально опубликовано AndyD
2. Ищем информацию по типам полей, входящих в индексы.

Похоже.
Только индексов будет недостаточно.
По-моему придется перебирать все поля таблиц.

[AndyD]

Я имел в виду уникальные индексы таблицы для которой мы ищем ссылки. Т.е. это подготовительный этап, разбираем сначала, что собственно надо искать.