Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну таблица Контрагент тоже есть, я ее не привел чтобы упростить ответ.
А так - да, Контрагент ---> Клиент ---> Реквизиты

автор
Как же ФИО может относиться и к физ лицам и к юр?
И видимо ФИО хранится в одном поле и используется либо как наименование организации, либо как фамилия имя отчество для физ/лица?

Ну что вы, как так можно? :) ФИО физлица для Юрика - это фио доверенного лица предприятия. А наименование организации лежит отдельно там где и положено - в реквизитах.

автор
видите, только из-за того что вы отвергаете мышление в терминах ООП вы сделали outer join, когда можно было join, что выполнится быстрее (незачем тащить реквизиты для физического лица). Это по мелочи.

При чем тут ООП? Я привел left join в качестве примера. Если мне нужны только физлица, то будет так:
select * from Client where Legal = 0
Если юрики, то так:
select * from Client C join LegalData L on (L.ClientID = C.ID) where C.Legal = 1
Та же скорость выполнения, так что нет никаких мелочей

автор
В принципе таблица реквизиты у вас тоже самое что и у меня юр/лицо и здесь тоже наследование (таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д).
Но явно не выделена сущность "Физическое лицо" и в этом ошибка проектирования.

А тут мне кажется совсем наоборот - у вас есть ошибочка, тут я согласен с www.fun4me.narod.ru :)

автор
Теперь дальше...
Возникло новое требование.
Требуется создать справочник сотрудников, при чем сотрудник может быть клиентом.
Ваш действия?

Ну, этак если дальше пойдет, мы систему тут напишем. Задаром
Это уже на усмотрение организации системы. Для чего нужен справочник сотрудников? Как и кто с ними будет работать. Можно заводить сотрудников отдельно, отдельно их как клиентов и связывать с клиентом, можно еще как-то, можно поставить отметку на клиенте о том, что он является сотрудником. Тут никак ООП не может влиять. Хотя вы все-же приведите, как бы сделали вы.
============
www.fun4me.narod.ru
Я бы сказал, что контагент - это обобщение понятия физических и юридических лиц. То есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо.

Или наоборот - при создании клиента сначала создается контрагент, а от него наследуется клиент. Тогда проще будет - хотя бы ID будут одинаковые.

-- Tygra's --
21 дек 04, 14:20    [1196777]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
Что еще хочется сказать по поводу сказанного Вами - в большинстве подобных задач запрос должен выглядеть как...

эти запросы во вью и завернуты. все так.

автор
Господа, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем...

Давайте, а то оффтоп пошел сплошной.
21 дек 04, 14:22    [1196791]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
softwarer
Реальные структуры предъявляют еще большие требование - например, стоит помнить, что банки (в которых у контрагентов расчетные счета) имеют корр.счета в других банках, а сами банки при этом являются организациями и могут являться контрагентами. Впрочем, не понимаю, при чем здесь объектный подход - это вопрос грамотного или неграмотного проектирования в условиях той или иной конкретной задачи. ER-проектирование - достаточно "объектно".

Полностью поддерживаю.

автор
Во всяком случае, наличие в 50 различных запросах фразы "[Юридическое лицо] JOIN [контрагент]" меня серьезно насторожит.

Ну у меня физики и без вьюх - это одна таблица. А так - да, вьюхи нужны. Тока в MS SQL они странно работают, планы у них часто слетают. Может просто не знаю, как лечить, но пока что вьюхами особо не увлекаюсь.

Роман Дынник
Это как? т.е. в контрагенте у вас будет 2-а поля одно из которых ссылается на ф/л, другое на ю/л? Это не правильно.

Нет, это будет скорее всего, как я выше написал.

автор
Это уже бизнеслогика.

Правильно, это все бизнес-логика и архитектура БД. И никакого ООП.

Shtock
Господа, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем...

Дык давно уж вопросы ушли вдаль от ответов. Или наоборот :)

-- Tygra's --
21 дек 04, 14:27    [1196812]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Можно и отдельный топик. Но это уже будет 3-й топик с ООП БД

-- Tygra's --
21 дек 04, 14:28    [1196826]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67389
Блог
tygra
Ну у меня физики и без вьюх - это одна таблица. А так - да, вьюхи нужны.

В таких общих справочниках все равно оказывается куча мелочей - например, у физика есть документ, удостоверяющий личность, и типы этих документов, по идее - отдельный справочник.

tygra
Тока в MS SQL они странно работают, планы у них часто слетают. Может просто не знаю, как лечить, но пока что вьюхами особо не увлекаюсь.

Хм. Как-то так оказывается, что когда я на rsdn.ru цитирую местные утверждения про MS SQL - там просыпаются Sinclair или Merle и начинают говорить: "ну-ка, покажи, откуда ты это взял?" :)

А что, у вьюхи в MS SQL есть какой-то фиксированный план? Немного странная концепция, имхо...
21 дек 04, 14:33    [1196850]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
softwarer
А кто сказал, что его можно завести? Для этого в Oracle Designer, например, существует специальное понятие "arc" - которое трансформируется в констрейнт примерно следующего вида

check ((a is not null and b is null) or (a is null and b is not null))


автор

А У нас так:
тбл. Контрагент (id,краткое наименование, инн)
тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование)
тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование)

для вывода всех клинтов: select * from контрагент
для вывода всех юриков: select * from [Юридическое лицо] JOINконтрагент
для вывода всех физ.лиц: select * from [Физическое лицо] JOINконтрагент


Я сказал, что в предложенной схеме:
[FIX]
тбл. Контрагент (id,краткое наименование, инн)
тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование)
тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование)
[/FIX]
можно завести контагентов, не являющихся ни физическим, ни юридическим лицом, и никакой constraint вида check ((a is not null and b is null) or (a is null and b is not null)) никому это сделать не запретит, даже если он создан по понятиям "arc"

И я был прав!
21 дек 04, 14:37    [1196878]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
Хотя вы все-же приведите, как бы сделали вы.

тбл. сотрудник(id, должность)+fk к физ.лицо (1-к-1 наследование) по id

для создания сотрудника
1) insert в контрагент
2) insert в физ.лицо
3) insert в сотрудник
везде id будет один и тотже (1-к-1)
это что бы ясно было.
А реально бедет такая последовательность и вложенность вызовов:
 
xsp_Ins_Employee(@id,@КраткоеНаименование,@ФИО,@должность)
     xsp_Ins_Person(@id,@КраткоеНаименование,@ФИО)
           xsp_Ins_Contragent(@id,@КраткоеНаименование)
              insert into contragent
           insert into Person
     insert into Employee
но все дело в том что я все эти xsp_Ins_xxx генерирую автоматом какая бы глубина наследования не была, поскольку они идентичны и хорошо формализованы, а в том получится ли это у вас, тигра, я не уверен...
21 дек 04, 14:41    [1196891]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67389
Блог
www.fun4me.narod.ru
И я был прав!

Виноват - автоматом протянул ссылки в правильную сторону :)

Я бы выдвинул к такой схеме другую претензию - можно завести контрагента, являющегося одновременно и физ-, и юр-лицом. Мало того, если действовать по частой для 1-1 схеме линковки по первичным ключам, это будет сделано автоматически - почти любой контрагент будет и физ., и юр.лицом (поскольку соответствующие записи будут в обеих таблицах).

Такие схемы, как правило, делают, одновременно разделяя по "все положительные - физики, все отрицательные - юрики)" или по другому аналогичному критерию. Но, с моей точки зрения, подобные игры со значениями ПК крайне нежелательны. Их можно оставить для каких-то системных вопросов, но частные прикладные решения лучше делать "как надо".
21 дек 04, 15:09    [1197029]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
контрагент будет и физ., и юр.лицом (поскольку соответствующие записи будут в обеих таблицах).

да не будет контрагент и физ и юр лицом одновременно никогда! либо физ, либо юр!
для физ будут записи: контрагент, физ
для юр будут записи: контрагент, юр
во вьюху физиков (физ JOIN контрагент) никогда не попадут записи из контрагент соответствующие юрикам.

во вьюху юриков (юр JOIN контрагент) никогда не попадут записи из контрагент соответствующие физикам.
21 дек 04, 15:21    [1197103]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67389
Блог
Роман Дынник
да не будет контрагент и физ и юр лицом одновременно никогда! либо физ, либо юр!
для физ будут записи: контрагент, физ
для юр будут записи: контрагент, юр

За счет чего их не будет? За счет того, что Ваша программа (если Вы нигде не ошибетесь) сгенерит сначала id для контрагента, а потом использует его как id для физика либо юрика? К надежности этого.. я люблю вспоминать фразу Хайнлайна.

- Знаешь, как мы называем женщин, полагающихся на календарный метод? Матерями.
21 дек 04, 15:27    [1197139]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
За счет того, что Ваша программа (если Вы нигде не ошибетесь) сгенерит сначала id для контрагента, а потом использует его как id для физика либо юрика? К надежности этого.. я люблю вспоминать фразу Хайнлайна

Не ошибется, т.к. все операции ч/з манипулирования данными ч/з хп. прямые инсерты в таблицы не допускаются. Манипулирование данными - это часть бизнес-логики.

И с такими рассуждениями любую схему подвергнуть сомнению можно, что мешает ошибиться и поставить в поле-признаке юр/лица вместо "0" "1"?
Этак мы вообще далеко сейчас уйдем.
21 дек 04, 15:37    [1197185]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
тбл. сотрудник(id, должность)+fk к физ.лицо (1-к-1 наследование) по id

для создания сотрудника
1) insert в контрагент
2) insert в физ.лицо
3) insert в сотрудник
везде id будет один и тотже (1-к-1)
это что бы ясно было.

Ну это один из способов, о множестве которых я говорил. Да, и так можно.

автор
но все дело в том что я все эти xsp_Ins_xxx генерирую автоматом какая бы глубина наследования не была, поскольку они идентичны и хорошо формализованы, а в том получится ли это у вас, тигра, я не уверен...

Вы не уверены, что я в состоянии написать N процедур для вставки во все таблицы? Ну...... Я был летом у шамана, так даже он мне такого не сказал. А вы, видать, покруче-то будете, раз на расстоянии (или через интернет) определяете мои способности :)). Нашел я более 1500 ХП, которые точно я написал (там есть опознавательные знаки). Пока что смог, надеюсь, что смогу и больше :)

автор
Хм. Как-то так оказывается, что когда я на rsdn.ru цитирую местные утверждения про MS SQL - там просыпаются Sinclair или Merle и начинают говорить: "ну-ка, покажи, откуда ты это взял?" :)

А что, у вьюхи в MS SQL есть какой-то фиксированный план? Немного странная концепция, имхо...

Ну не знаю лично, есть ли план у вьюхи, но то, что если в выборках использовать вьюху, и не одну, то очень часто бывает, что вдруг слетают планы у ХП и именно из-за вьюхи, да и вообще непредсказуемо поведение. Ну это на достаточно сложных вьюхах, больше 2-х таблиц с некоторыми параметрами. На простых вроде ничего.

-- Tygra's --
21 дек 04, 15:59    [1197331]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67389
Блог
Роман Дынник
Не ошибется, т.к. все операции ч/з манипулирования данными ч/з хп. прямые инсерты в таблицы не допускаются. Манипулирование данными - это часть бизнес-логики.

Тогда - готовьте пеленки :)

Роман Дынник
И с такими рассуждениями любую схему подвергнуть сомнению можно, что мешает ошибиться и поставить в поле-признаке юр/лица вместо "0" "1"?

А какой идиот будет вводить такой признак?
21 дек 04, 16:08    [1197385]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
А какой идиот будет вводить такой признак?

кое-кто вводит...

2Тигра
автор
Вы не уверены, что я в состоянии написать N процедур для вставки во все таблицы

Да уверен, уверен :)) просто я их не пишу, они у меня сами ГЕНЕРЯТСЯ (сами пишутся на основании ER-модели.
21 дек 04, 16:24    [1197450]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Да я уж сам, по-старинке, руками :)) Тем более, что там есть еще кое-какая обработка, так что автоматически от силы 5% ХП можно сгенерить.

-- Tygra's --
21 дек 04, 16:29    [1197482]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67389
Блог
Роман Дынник
Да уверен, уверен :)) просто я их не пишу, они у меня сами ГЕНЕРЯТСЯ (сами пишутся на основании ER-модели.

2tygra (задумчиво): пофлеймить на тему "нахрена такие процедуры нужны"? Или пожалеть нервы читателей?
21 дек 04, 16:30    [1197488]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
А кстати, softwarer то сам как эту "задачку" решит? С юриками-физиками

-- Tygra's --
21 дек 04, 16:31    [1197490]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67389
Блог
tygra
А кстати, softwarer то сам как эту "задачку" решит? С юриками-физиками

Тогда уж постановку дайте :) А то основная причина флейма в таких темах - каждый говорит о задаче, которая у него когда-то была применительно к серверу, которым пользуется.
21 дек 04, 16:33    [1197507]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
Да я уж сам, по-старинке, руками :)) Тем более, что там есть еще кое-какая обработка, так что автоматически от силы 5% ХП можно сгенерить.

Ну вот... а у меня 70-80%
Вопрос подхода...

автор
пофлеймить на тему "нахрена такие процедуры нужны"? Или пожалеть нервы читателей?

Пофлейми, пофлейми, раз делать нечего.
Все идут к тому чтобы сократить количество ручного коддинга, а ты еще флеймить собрался по поводу "надо или не надо".
Этак у нас бы сейчас ни case-средств не было ни UML, и на коленках бы рисовали.
21 дек 04, 16:36    [1197520]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67389
Блог
Роман Дынник
Пофлейми, пофлейми, раз делать нечего.
Все идут к тому чтобы сократить количество ручного коддинга, а ты еще флеймить собрался по поводу "надо или не надо".
Этак у нас бы сейчас ни case-средств не было ни UML, и на коленках бы рисовали.

Судя по этому заявлению, я верно оценил Ваш уровень.

hint: такая практика не сокращает количество ручного кодирования, а только добавляет кучу малоосмысленного автосгенеренного кода.
21 дек 04, 16:41    [1197540]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
сплошные оскарбления пошли, что за народ такой неуважительный...
21 дек 04, 16:44    [1197554]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автосгенерированный код вполне осмысленный получается, вручную я написал бы тоже самое.

вот пример(сгенерировано все до запятой):

create procedure xsp_Ins_Person
(
@TicketSID		TSID,
@SID		            TSID        out,
@ID		                int         out,
@SysObjSysClSID		TSID ,
@SysObjSysFolderSID		TSID ,
@SysObjOwnerSID		TSID out,
@SysObjDTCreate		datetime out,
@SysObjDTLastChange		datetime out,
@SysObjUIDLastChange		TSID out,
@SysObjIsDel		TFlagYesNo ,
@SysFolderSysClSID		TSID ,
@SysFolderName		TUserName ,
@SysFolderisRootClFolder		TFlagYesNo ,
@SysFolderLFT		int ,
@SysFolderRGT		int ,
@ContragINN		TINN ,
@ContragNote		TNote ,
@PersFirstName		TUserName ,
@PersLastName		TUserName ,
@PersMiddleName		TUserName 
)
as
begin
BEGIN TRAN
exec xsp_mkSpHeader @TicketSID , @SysObjOwnerSID out, @SysObjSysClSID	out, 'Person', @@NESTLEVEL
if @@error<>0 GOTO UNDO
exec xsp_Ins_Contragent
@TicketSID		,
@SID		out,
@ID		out,
@SysObjSysClSID		,
@SysObjSysFolderSID		,
@SysObjOwnerSID		out,
@SysObjDTCreate		out,
@SysObjDTLastChange		out,
@SysObjUIDLastChange		out,
@SysObjIsDel		,
@SysFolderSysClSID		,
@SysFolderName		,
@SysFolderisRootClFolder		,
@SysFolderLFT		,
@SysFolderRGT		,
@ContragINN		,
@ContragNote		


if @@error<>0 GOTO UNDO
insert into Person 
(
SID,
ID,
PersFirstName,
PersLastName,
PersMiddleName
)
 values
(
@SID		,
@ID		,
@PersFirstName		,
@PersLastName		,
@PersMiddleName		
)
if @@error<>0 GOTO UNDO
if @@TRANCOUNT>0 COMMIT TRAN
return(0)
UNDO:
if @@TRANCOUNT>0 ROLLBACK TRAN
end
go
И что тут мало осмысленного?
21 дек 04, 16:48    [1197571]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> И что тут мало осмысленного?

А почему процедура код ошибки не возвращает?
21 дек 04, 16:52    [1197585]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
Проверка if @@error<>0 GOTO UNDO после вызова процедуры не гарантирует успешного её выполнения. Да и в остальном - осмысленности не много, но это моё личное мнение.
21 дек 04, 16:58    [1197614]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
Вот пример для размышления:
create procedure bad_generated_code
as
begin
    begin transaction
    select 1/0
    rollback transaction
end
go
exec bad_generated_code
select @@error

Так что - срочно переписывайте весь свой автосгенерённый код
21 дек 04, 17:09    [1197660]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить