Показать сообщение отдельно
Старый 12.01.2012, 14:50   #4  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Интересная штука, но, судя по документации, реализовано с неким анально-ориентированным уклоном.
  1. RecId уникален в рамках таблицы
  2. генерация RecID в разные таблицы независимы
  3. Цитата:
    Сообщение от sukhanchik Посмотреть сообщение
    Важно! RecId производной таблицы совпадает с RecId базовой, т.о. в производной таблице может быть не более одной записи, соответствующей записи в базовой (родительской) таблице.

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

Суть такой модификации - наследование RecId из базовой таблицы при вставке в наследуемые, при этом вот что получится при вставке в таблицу потомка нижнего уровня N, если для него нужен такой же RecId, как и у базовой:
  • Попытка вставки в наследника уровня N - запрос RecId от родителя (наследника уровня N-1)
  • Попытка вставки в наследника уровня N-1 - запрос RecId от родителя (наследника уровня N-2)
  • ...
  • Попытка вставки в наследника уровня 1 - запрос RecId от родителя (базовой таблицы)
  • Вставка в базовую таблицу (передача RecId потомку 1 уровня)
  • ...
  • Вставка в таблицу потомка уровня N-2 (передача RecId потомку N-1 уровня)
  • Вставка в таблицу потомка уровня N-1 (передача RecId потомку уровня N)
  • Вставка в таблицу потомка уровня N
Зачем эти лишние вызовы и ожидания? Только для выполнения странной связи по RecId с обоих сторон join'а ? Как скажется на быстродействии вставки и блокировках на SystemSequences подобный многоступенчатый механизм, гарантирующий выполнение уникальности RecId по таблице и равные RecId у связанных записей в таблицах потомков/родителей ?


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

Select Родитель Left Outer Join
Потомок On Родитель.InstanceRelationType = Потомок.TableId And Родитель.InstanceRelationRecId = Потомок.RecId
.
__________________
Мы летаем, кружимся, нагоняем ужасы ...
За это сообщение автора поблагодарили: gl00mie (5).