Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как лучше сделать ссылку на 2 сущности ? (Oracle и MS SQL)


Страницы:   1 2 3

ANB ©   (2005-12-20 12:01:00) 

Пример из налоговой (бухгалтерии) :
Есть 2 сущности : налогоплательщики юридические лица и физические лица. Естественно, набор полей - атрибутов у них отличается и логично хранить их в разных таблицах.
Из многих таблиц ссылка может быть как на ЮЛ, так и на ФЛ.
Видел несколько способов реализации подобного :
1. Отдельные таблицы ЮЛ и ФЛ. Завести в подчиненных таблицах по 2 ссылочных поля - отдельно на ЮЛ, отдельно на ФЛ. Повесить честные FK. Проблема - надо либо анализировать оба поля на null/0 либо добавлять поле - тип связки. Все это потом сильно усложнит запросы. Плюс придется вешать излишние составные индексы.
2. Отдельные таблицы ЮЛ и ФЛ. Организовать уникальность ID в этих таблицах (исключить пересечение). В ссылочное поле пишем просто ID. Проблемы - FK идут в лес, проверка целостности только хранимкой, запросы тоже не простые, в MS SQL в лес идут автоинкрементальные ID (В оракле просто общий секвенсер).
3. Дерево с ветками. Делаем 3 таблицы : Налогоплательщики (с общими полями для ЮЛ и ФЛ), отдельно ФЛ и ЮЛ, ссылающиеся на стержневую общую таблицу всех налогоплательщиков. Запросы писать легко. Работать будет намного шустрее первых 2-х способов. Минус - если удалять записи из таблицы, например, ФЛ, а в основной - не удалять, то получим висячие записи, т.к. FK это не отследит. Т.е. без проверки на хранимке тут не обойтись.

Какой способ лучше или есть свои мысли ?


Курдль   (2005-12-20 17:27:00) [1]


> evvcom ©   (20.12.05 17:18) [39]
> А если в "ДатаСэт" самом ошибка?


ДатаСэты тоже компилятся и многие ошибки в них выявляются на этапе создания. Однако, я не могу себе представить ошибку при создании такого ДатаСэта, если его "рисуют" прямо с ER-модели БД. Некоторые CASE-интрументы умеют создвавть ДатаСэты прямо "не отходя от кассы" (но я не пробовал).


Курдль   (2005-12-20 17:20:00) [2]


> ANB ©   (20.12.05 17:03) [38]
> А если в это время кто то правит справочник ?


Тогда уже СУБД ругнется, если что-то не так. Не в этом дело.


> Имхо, такой проверятельный автомат можно и на делфи + одак
> замутить. Плотной работы максимум на месяц. Зато все преимущества
> одака перед адо сохраняться.


ODAC (DOA), ADO - это уже все не важно. Замутить тоже ничего не надо.
ADO.NET - это уже новая ступень эволюции. При всем моем ... э-э-э... скептическом отношении к Microsoft, здесь я снимаю шляпу. Сравнивать невозможно. К Delphi я возвращаюсь только для создания очень простых мимолетных проектов. Все остальное - VS.NET  И вряд ли теперь что-то изменится...


evvcom   (2005-12-20 17:18:00) [3]


> можно заполнить необходимую структуру данных на клиенте
> не опасаясь скрытых ошибок (их выявит сам ДатаСэт на этапе
> заполнения)

А если в "ДатаСэт" самом ошибка?


ANB   (2005-12-20 17:03:00) [4]


> Теперь можно заполнить необходимую структуру данных на клиенте
> не опасаясь скрытых ошибок (их выявит сам ДатаСэт на этапе
> заполнения), и отправить эти данные на сервер, будучи уверенным,
>  что с ними все Ок

А если в это время кто то правит справочник ?
Имхо, такой проверятельный автомат можно и на делфи + одак замутить. Плотной работы максимум на месяц. Зато все преимущества одака перед адо сохраняться.


Курдль   (2005-12-20 16:56:00) [5]


> evvcom ©   (20.12.05 16:29) [35]
> А... Т.е. то что реализовано в серверных СУБД (в частности
> Oracle) теперь еще и на клиента вытащили? Ну в смысле структуру.
>  Ну не зря, наверное.


Еще как не зря! Я прочувствовал, как начал работать с трехзвенками, где клиент удаленный. Теперь можно заполнить необходимую структуру данных на клиенте не опасаясь скрытых ошибок (их выявит сам ДатаСэт на этапе заполнения), и отправить эти данные на сервер, будучи уверенным, что с ними все Ок.
Еще один плюс многотабличных датасэтов - возможность передавать данные "всем скопом" через механизм .NET Remoting.
Т.е. пишешь метод удаленного объекта, который принимает параметром (или возвращает) такой датасэт и все! Данные ходят между доменами, строго придерживаясь описанной структуры.


evvcom   (2005-12-20 16:33:00) [6]


> Нормальный FK сделай с каскадным удалением (если надо).

Тогда 2 FK (друг на друга) :) Разговор был о том, что если в главной удаляешь, то в подчиненной естественно каскадно записи удалятся, а если наоборот? Если в подчиненной грохнуть, то в главной-то останутся "висяки".


evvcom   (2005-12-20 16:29:00) [7]

А... Т.е. то что реализовано в серверных СУБД (в частности Oracle) теперь еще и на клиента вытащили? Ну в смысле структуру. Ну не зря, наверное.

> Я имел в виду линейность данных типа "запись1, запись2,
> запись3 ... записьN".

тогда

> В Delphi нет таблиц данных (в смысле СУБД)

А если говорить про то, что ты видел или не видел, то NestedTables как раз и есть эти вложенные таблицы. И тут уже линейности нет.
Просто ты думал о "среде", а говорил об "отсутствии нелинейности".

> Какая разница, что поддерживает оракл, если это не поддерживает
> среда?

"Среда"-то поддерживает, просто не в том виде и не том, может быть, объеме.


Reindeer Moss Eater   (2005-12-20 16:28:00) [8]

Создать иерархию классов в оракле и одну таблицу основанную на базовом классе. В ней будут и те и эти.


Desdechado   (2005-12-20 16:22:00) [9]

ANB ©   (20.12.05 14:09) [15]
>> поэтому опасения, что при удалении из подчиненной главная
>> запись осиротеет, имхо, надуманны
> Если бы. Как только повесишь ссылочную целостность на хранимки
Где я предлагал на хранимки что-то весить? Нормальный FK сделай с каскадным удалением (если надо).


Reindeer Moss Eater   (2005-12-20 16:15:00) [10]

Иерархия классов.

1.Налогоплательщик.
1.1 Налогоплательщик->Юрик
1.2 Налогоплательщик->Физик


Курдль   (2005-12-20 15:57:00) [11]


> evvcom ©   (20.12.05 15:43) [30]
> Ну так в Оракле это NestedTables, и ODAC это тоже поддерживает.


Это другое. Какая разница, что поддерживает оракл, если это не поддерживает среда?

В "Visual Studio .NET" (Думаю и в Delphi 8) ДатаСэты не просто "перетаскиваются на форму" и получают неоходимые свойства и т.п., а перед этим создаются разработчиком, как новый класс - наследник от System.Data.DataSet. Т.е. рисуются в графической оболочке VS, как диаграмма данных (таблица - поля - ключи - связь таблица поля - внешние ключи, констрэйнты и т.д.). После этого они именуются и хранятся в проекте отдельными файлами. Если форма будет использовать такой ДатаСэт, то в дизайн-тайме он "привязывается" к форме. Это значит, что в методе инициализации формы будет создан нужный ДатаСэт и его поля (таблицы) будут привязаны (binding) к соотв. элементам отображения и управления данными.


> ммммм... В Delphi нет таблиц данных (в смысле СУБД), а если
> говорить, про данные (не СУБД) в Delphi, то они тоже не
> все линейные. Или ты про BDE? Но это уже и не Delphi. :)

Я имел в виду линейность данных типа "запись1, запись2, запись3 ... записьN".


evvcom   (2005-12-20 15:43:00) [12]


> Например ДатаСэт, исползуемый в форме редактора физ. лица
> может содержать таблицу "ФИЗ_ЛИЦА", "ПАСПОРТА", "АДРЕСА".

Ну так в Оракле это NestedTables, и ODAC это тоже поддерживает.

> В ADO.NET датасэт представляет собой не линейный список
> данных, как в Delphi, а совокупность таблиц

ммммм... В Delphi нет таблиц данных (в смысле СУБД), а если говорить, про данные (не СУБД) в Delphi, то они тоже не все линейные. Или ты про BDE? Но это уже и не Delphi. :)


Sergey13   (2005-12-20 15:42:00) [13]

2[28] Курдль ©   (20.12.05 15:33)
> В ADO.NET датасэт представляет собой не линейный список данных, как в Delphi
Так и в Делфи можно замутить вроде.


Курдль   (2005-12-20 15:33:00) [14]


> evvcom ©   (20.12.05 15:14) [24]
> > многокурсорные НД?
> все-таки многокурсорные DataSet's


Повторяю: многотабличные ДатаСэты

В ADO.NET датасэт представляет собой не линейный список данных, как в Delphi, а совокупность таблиц (с полями идентификаторами и ключами), связей и правил. Т.е. ДатаСэт представляет собой фрагмент диаграммы базы данных, наполненный данными.
Например ДатаСэт, исползуемый в форме редактора физ. лица может содержать таблицу "ФИЗ_ЛИЦА", "ПАСПОРТА", "АДРЕСА". Последние связаны с первой "много-к-одному" по ключу SBJ_ID. Для них по умолчанию установлено правило каскадного обновления.


Sergey13   (2005-12-20 15:29:00) [15]

2[25] ANB ©   (20.12.05 15:15)
>Если вздумается довесить еще одну вектовую таблицу, то придется столбовую альтерить.

Так потому я и уточнял
[12] Sergey13 ©   (20.12.05 13:46)
Если число типов сущностей невелико и постоянно

Впрочем, не такая уж и проблема, ИМХО, если таблица добавляется, то и другую изменить можно. Чай не бетонная. 8-)


evvcom   (2005-12-20 15:28:00) [16]


> Ессно, программисты это требование игнорят и понеслась . . .

Ессно! Кому хочется сидеть, выбирать данные и подставлять по одиночке в ХП? Даже курсор написать и то лень. Гораздо проще один delete (update, insert). А чтобы не "понеслась ..." надо эту логику в триггер зашивать, а не в хранимку


ANB   (2005-12-20 15:15:00) [17]


> Sergey13 ©   (20.12.05 15:06) [23]

Если вздумается довесить еще одну вектовую таблицу, то придется столбовую альтерить.


> А вот как это на ХП?..

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


evvcom   (2005-12-20 15:14:00) [18]


> многокурсорныеНД?

все-таки многокурсорныеDataSet's


Sergey13   (2005-12-20 15:06:00) [19]

2[15] ANB ©   (20.12.05 14:09)
>Только проблема навыворот - тогда можно будет удалять запись из столбовой таблицы, а конкретизирующие из веток останутся.

Если на нее ссылок нет - то конечно. Но можно и тригерок повесить. 8-)
По сути столбовая табла тут работает как вьюха на объединение нескольких таблиц.


evvcom   (2005-12-20 15:06:00) [20]


> Ты чего это за временем-то гоняешься? Миллиарды записей
> клиенту выдаешь?

Причем тут клиент? Джойн на сервере делается. Другое дело, если ты скажешь, что изначально (перед джойном) данные плохо фильтруются (высокая селективность). А если клиент хочет получить отчет, а для него во внутреннем селекте высокая селективность, потом джойн (может даже многомиллионный, но один к одному), а потом только аггрегирование. Клиенту выдается всего пара сотен записей в отчет, но сервер перелопатил и наджойнил несколько миллионов записей.

> а среднестатистический запрос обращается к 10 и более таблицам
> по разнообразным джоинам

У меня тоже их не мало и тоже, можно сказать, все ок. Но таблица таблице рознь.

> но такое возможно только при использовании многотабличных
> ДатаСэтов ADO.NET

Не только ADO. Ты вроде сейчас с Ораклом работаешь? ODAC тоже такое поддерживает, если я правильно понял, о чем ты говоришь. Ты имеешь ввиду многокурсорныеНД?


Страницы:   1 2 3

Наверх

Титульная страница Поиск, карта сайта Написать письмо