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. Если эта строка принадлежит виртуальной компании, то необходима будет проверять по всем компаниям, входящим в виртуальную.
В общем так. Я ничего не забыл?