![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как лучше сделать ссылку на 2 сущности ? (Oracle и MS SQL)
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 тоже такое поддерживает, если я правильно понял, о чем ты говоришь. Ты имеешь ввиду многокурсорныеНД?