![]() |
#8 |
Участник
|
2 mazzy
2. Если RecID отсутствует, то тут и ссылаться не на что. Вообще, по-моему, случай с RecID самый сложный, так как приводит к необходимости проверять все таблицы, где используется тип recId или его наследники. Да и индекса по этому полю может не быть. 3. Этот пункт вообще не понял. ![]() По моему алгоритм поиска будет выглядеть следующим образом: 1. Вытаскиваем из AOT информацию по уникальным индексам этой таблицы и наличию поля recId. 2. Ищем информацию по типам полей, входящих в индексы. 3 Ищем наследников этих типов, проверяем, было ли изменение релейшенов в них (перенаправление на другую таблицу), если было, то отбрасываем. 4. Ищем наследников EDT recId, если это поле есть в таблице. Возможно в наследниках определены релейшены, что облегчит поик по таблицам и сузит круг исследуемых типов. 5. Проверяем все таблицы на наличие в них полей, входящих в индексы (по типам полей, полученных в пп. 2 и 3). Если хотя бы одно поле из индекса не входит в таблицу, то этот индекс не рассматриваем. 6. Параллельно с п. 5 проверяем релейшены на таблицах, возможную ссылку на исследуемую таблицу. 7. Параллельно с пп. 5 и 6 проверяем, есть ли в таблице поля, имеющие типы, полученные в п. 4, кроме собственного поля recId этой таблицы. 8. Для ускорения собственно поиска рассматриваем существующие индексы на таблицах, вхождение отсеянных в пп. 5-7 полей в эти индексы. Предпочтение отдаем индексам в которых эти поля входят в порядке, указанном в уникальном индексе. В итоге получаем список таблиц и их полей, по которым необходимо проверять связи. Для ускорения поисков, возможно, придется использовать перекрестные ссылки. Дальше идет собственно сам поиск по полученным в пп. 5-7 таблицам с использованием индексов, полученных в п. 8. Если эта строка принадлежит виртуальной компании, то необходима будет проверять по всем компаниям, входящим в виртуальную. В общем так. Я ничего не забыл? |
|
|
|