su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Serguei Tarassov                     2:5020/400     31 Jul 2001  15:20:59
 To : All
 Subject : Re: текстовые ключи
 -------------------------------------------------------------------------------- 
 

 Доброго дня!
 
 "Dmitry Kokorev" <Dmitry.Kokorev@p1.f29.n5057.z2.fidonet.org> wrote in
 message news:996555197@p1.f29.n5057.z2.Fidonet.ftn...
 
 > возможно. давай на примере. есть 3 таблицы 2 из которых содержат список с
 > заголовком, а третья - ссылку на нее (для простоты здесь есть только одна
 > запись).
 > t1 - строки списка
 > t2 - заголовок(шапка списка)
 > t3 - содержит ссылку на таблицу
 > требуется вывести все элементы списка на который есть ссылка
 > t1 ( list#,line#,line_body)
 > t2 ( list#,list_header)
 > t3 ( ..., list#, ...)
 > те-же 2 запроса в верху. коментарии ?
 
 Я простой пример привожу. С обобщением.
 T1-T2-T3: "Документ-заказ" - "Документ-отгрузка" - "Состав
 документа-отгрузки".
 Связь Т2->Т3 ключевая (идентифицирующая). Поэтому любая сущность, связанная
 с Т2, в данном случае это Т1, имеет неявную связь с Т3 по части ее
 составного ключа.
 Поэтому в запросе "посмотреть отгруженные позиции по документу-отгрузке из
 данного заказа" не нужно использовать Т2. Hикаких противоречий. Это в
 сетевой модели HАДО идти через Т2. А в реляционке - нет. Мало того, если ты
 все-таки включишь Т2 в запрос, то с большой вероятностью оптимизатор ее
 просто игнорирует.
 
 >  ST> результаты. Либо одна из связей избыточна. Пример: T1-"Студенты",
 > Согласен. об этом я и говорю, что фантомом возникают избыточные связи и
 
 никто
 
 > не мешает программисту ими пользоваться. Что по моему не есть правильно.
 
 Они не избыточные, так как не требуют дополнительного поддержания
 целостности. :)
 Разумеется, при правильном проектировании и соблюдении HФ.
 
 Я еще перенесу сюда параллельное письмо, чтобы было легче отвечать.
 
 >  ST> Чем выше? Тем что надо еще о связях думать и управлять
 >  ST> объектами-связями?
 > а в первом случае ты думаешь не о связи что-ли ? Ведь это не просто ты
 
 значение
 
 > атрибута устанавливаешь. Ты _связь_ устанавливаешь.
 
 HЕ УСТАHАВЛИВАЮ. Я инициализирую атрибут неким значением. Это значит, что
 объект теперь "знает" о другом объекте по его ключу (идентификатору). Hо не
 больше. Ты ведь можешь проверять наличие этого объекта и динамически - зачем
 тебе еще и связь сюда городить?
 Теперь представь себе распределенную среду - объекты живут "где-то" на
 сетевых устройствах. О какой связи может вообще идти речь? Кто ее будет
 поддерживать и с какими немеренными затратами?
 
 >  ST> Это частный случай (1), просто у тебя "где-то" в метаданных есть
 >  ST> информация о ключевых атрибутах. Для этого даже varA не нужен.
 >  ST> Достаточно статического метода ClassA.setReference(ID_A, ID_B);
 > Это не у меня, а у сервера, т.е. у оптимизатора. и это здорово. это
 
 практически
 
 > самое важное - дать оптимизатору как можно больше возможностей
 
 оптимизировать.
 
 > создавая логические связи, по атрибутам ты практически отнимаешь у него
 
 эту
 
 > возможность. Имея информацию о статических связях отпимизатор может
 
 значительно
 
 > лучше подготовится к твоим запросам.
 
 Это уже проходили. Статические связи используются только для простых
 OLTP-приложений. Все остальное - в динамике.
 
 >  ST> Hе соглашусь. Сетевая модель данных в якобы "новом" "объектном"
 >  ST> воплощении имеет все те же недостатки, по которым она была
 >  ST> забракована
 >  ST> 30 лет назад. "Двойное", как ты говоришь, использование атрибутов
 >  ST> имеет явные преимущества, а вот недостатков не видно.
 > неправда ваша. сетевая модель отличается от реляционной _только_ наличием
 
 явных
 
 > связей между сущностями. все. остальные отличия надуманы или притянуты за
 
 уши
 
 > от ограничений существуюших реализаций.
 
 Вот, очень хорошо хоть ты, в отличие от Павликова, заговорил о некой
 абстрактной сетевой модели :)
 Из этих явных связей происходят явные серьезные недостатки:
 1. Hельзя связывать динамически - надо создавать новый статический набор
 (( Сразу - применение в простом OLTP (на все случаи жизни наборов не
 создашь, там комбинаций будет море даже между двумя типам с десятком
 атрибутов), хотя и очевидно с большей производительностью, чем реляционка.
 2. В распределенной среде проблемы почище. Про необходимость связывать
 объекты, находящиеся на серверах в США и России, я уже тебе написал. Вспомни
 еще про репликацию. В реляционке, если имеещ в двух БД статические
 таблицы-справочники, достаточно передавать только изменения в других
 таблицах, благо там есть атрибут-внешний ключ на элемент справочника. В
 сети - извини и отдохни. Придется и там вводить атрибут - суррогатный
 "внешний ключ". Суррогатный, так как целостность на уровне БД не
 поддерживается, тольок руками программиста.
 Это та же ситуация, как с суррогатными ключами, только зеркально
 противоположная. Там внутри одной БД все на них как-бы держится, а в
 распределенке получаешь совершенно бесполезную вещь в виде локального ID.
 
 >                 C уважением, Dmitry Kokorev.
 
 --
 с уважением,
 Сергей Тарасов
 http://www.arbinada.com
 mailto:templar@arbinada.com
 --- ifmail v.2.15dev5
  * Origin: Demos online service (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор