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

>Ничего она (Java) не мешается, Oracle-у уж точно :), а что касается Sybase дык писать нужно лучше чтоб под ногами java не мешалась.

Так никаких проблем, джава в сайбейзе есть, все замечательно, только использовать ее почему-то никто не хочет. Почему вдруг все дружно игнорируют джаву в SQL сервере?
21 дек 04, 04:32    [1195264]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
Ну во первых кто мешает вызывать просто sp_Ins5(@xml), передавая туда сразу все аттрибуты класса и его предков ? 
Мы же про передачу иерархического объекта заговорили в виде xml в сравнении с java-объектом.
Во вторых Вы пытаетесь на РСУБД наложить ООП, а при моем подходе это просто ни к чему. Зачем спрашивается на уровне клиента плодить бизнес-классы, если вся бизнес-логика лежит на СУБД и от клиента требуется ума только получить данные в виде набора данных, показать их для просмотра, организовать их отложенное изменение и потом пакетно сохранить все изменения ?
Сейчас многие так и поступают, именно на РСУБД накладывают ООП, и это правильно, иначе при огромном количестве сущностей поддержка проекта превращается в сущий ад в котором может разобраться только "основной" разработчик. Потом, у меня, например, как я уже говорил ВСЯ бизнес-логика на сервер не переносится. На сервер переносятся только CRUD операции в виде слоя хп. Что же касается бизнес-логики (далее БЛ) по части различных проверк на корректность ввода, в ряде случаев (не во всех) ветвлений if-ов - по моему мнению это дело именно среднего звена (если мы говорим о многозвенной арх-ре). При этом часть БЛ касающаяся проверки на корректность ввода дублируется и в среднем звене и на клиенте. И все это способствует масштабированию.
 Для организации такой работы в любой среде построения клиентов сейчас существуют стандартные компоненты доступа к данным, их визуального просмотра и построения отчетов. Этого вполне достаточно, чтобы организовать клиента в виде GUI приложения или интернет-проекта.
У меня стандартные компоненты доступа к данным используются для заполнения и просмотра списков и именно в этом их основное предназначение (если говорить о различных recordeset, dataset, reader-ах).

В данном случае по моему личному мнению ООП будет использоваться по прямому его назначению - быстрой организации и легкой поддержки интерфейсной части. Всякие попытки перенести бизнес-обьекты на классы и потом танцевать с бубном по проведению их хранения и эффективности обработки на РСУБД только усложняют задачу.
Странно, но мне как раз все это облегчает задачу.
Я знаю что вы являетесь поклонником продуктов Sybase...
Так вот, PD мне сильно облегчает жизнь в плане написания CRUD, и именно тем что при проектировании БД я использую ОО подход. Весь слой CRUD, а это порядка 70-80% всех хп в проекте генерируется VBSсript-ом на основании концептуальной модели данных, в соответствии с наследованием сущностей и их атрибутами.
В некоторых системах используются всякие Persistence/mapping компоненты, которые позволяют автоматически сохранять ОБЪЕКТ в БД (мапить его на sql-выражения) без особых услилий. Т.е. не нужно заботиться о создании слоя хп или прямых запросах. И эти компоненты давно ТАКЖЕ давно стали стандартными (JDO-java data object например). Лично я их не использую, именно потому что не нашел нигде маппинг на хп, но они, в ряде случаев, позволяют значительно сократить сроки разработки для небольших и средних проектов, а также используются в настраиваемых ERP-системах.
где ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения. 
ООП полезно везде. Пора перестать мыслить таблицами и полями.
21 дек 04, 10:23    [1195596]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
Ну во первых кто мешает вызывать просто sp_Ins5(@xml), передавая туда сразу все аттрибуты класса и его предков ?

Мы же про передачу иерархического объекта заговорили в виде xml в сравнении с java-объектом.
автор
Во вторых Вы пытаетесь на РСУБД наложить ООП, а при моем подходе это просто ни к чему. Зачем спрашивается на уровне клиента плодить бизнес-классы, если вся бизнес-логика лежит на СУБД и от клиента требуется ума только получить данные в виде набора данных, показать их для просмотра, организовать их отложенное изменение и потом пакетно сохранить все изменения ?

Сейчас многие так и поступают, именно на РСУБД накладывают ООП, и это правильно, иначе при огромном количестве сущностей поддержка проекта превращается в сущий ад в котором может разобраться только "основной" разработчик. Потом, у меня, например, как я уже говорил ВСЯ бизнес-логика на сервер не переносится. На сервер переносятся только CRUD операции в виде слоя хп. Что же касается бизнес-логики (далее БЛ) по части различных проверк на корректность ввода, в ряде случаев (не во всех) ветвлений if-ов - по моему мнению это дело именно среднего звена (если мы говорим о многозвенной арх-ре). При этом часть БЛ касающаяся проверки на корректность ввода дублируется и в среднем звене и на клиенте. И все это способствует масштабированию.
автор
Для организации такой работы в любой среде построения клиентов сейчас существуют стандартные компоненты доступа к данным, их визуального просмотра и построения отчетов. Этого вполне достаточно, чтобы организовать клиента в виде GUI приложения или интернет-проекта.

У меня стандартные компоненты доступа к данным используются для заполнения и просмотра списков и именно в этом их основное предназначение (если говорить о различных recordeset, dataset, reader-ах).

автор
В данном случае по моему личному мнению ООП будет использоваться по прямому его назначению - быстрой организации и легкой поддержки интерфейсной части. Всякие попытки перенести бизнес-обьекты на классы и потом танцевать с бубном по проведению их хранения и эффективности обработки на РСУБД только усложняют задачу.

Странно, но мне как раз все это облегчает задачу.
Я знаю что вы являетесь поклонником продуктов Sybase...
Так вот, PD мне сильно облегчает жизнь в плане написания CRUD, и именно тем что при проектировании БД я использую ОО подход. Весь слой CRUD, а это порядка 70-80% всех хп в проекте генерируется VBSсript-ом на основании концептуальной модели данных, в соответствии с наследованием сущностей и их атрибутами.
В некоторых системах используются всякие Persistence/mapping компоненты, которые позволяют автоматически сохранять ОБЪЕКТ в БД (мапить его на sql-выражения) без особых услилий. Т.е. не нужно заботиться о создании слоя хп или прямых запросах. И эти компоненты давно ТАКЖЕ давно стали стандартными (JDO-java data object например). Лично я их не использую, именно потому что не нашел нигде маппинг на хп, но они, в ряде случаев, позволяют значительно сократить сроки разработки для небольших и средних проектов, а также используются в настраиваемых ERP-системах.
автор
где ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения.

ООП полезно везде. Пора перестать мыслить таблицами и полями.
21 дек 04, 10:27    [1195609]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
>>>c127
Не используют потому что не привыкли, потому что мыслят таблицами и записями, потому что надо время на изучение а его нет, потому что не везде целесообразно применять java-процедуры.
Если признаться, раньше я и сам задавался вопросом где и зачем они мне могут понадобиться.
21 дек 04, 10:35    [1195638]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
ООП полезно везде. Пора перестать мыслить таблицами и полями.

Да-да, и еще пора опять переносить бизнес-логику на клиента, делать в каждой системе обязательное среднее звено, доступ к БД может быть только через клиента или среднее звено......
А может все же облегчить себе жизнь?
Иногда нужно помыслить таблицами и полями - проще жить станет, намного проще.
А еще ООП не надо переносить на данные и вообще на все, что шевелится :) - это технология разработки и программирования приложения, но никак не технология манипулирования данными.

Вы расскажите смысл представления данных как объектов? Я вот не вижу. И гораздо проще иметь набор таблиц с полями, с которыми можно сделать что угодно, которые являются родными по отношению к СУБД - и следовательно проще и быстрее их обрабатывать и т.д.

В Оракле вот давно есть возможность создавать пользовательские типы данных, с методами, свойствами... Ну и что, много кто ее использует, эту возможность?

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

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну и опять же легкость поддержки системы - если у вас логика зашита в клиента и вам нужно чего-то изменить, но не в выводе информации для клиента, а именно часть бизнес-логики, то вам придется каждый раз компилять клиента и выкладывать пользователям. В случае же бизнес-логики на сервере, ничего никуда ненадо выкладывать - все меняется для всех прозрачно. Вы еще не почувствовали разницу? Может вы просто не пробовали сделать обычное приложение с обычной РСУБД? Попробуйте.

Почему всегда забывают про поддержку (изменение, дополнение, исправление) системы??? Хотя это 70% работы. Но на это наплевать? Мда.

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

Откуда: Симферополь
Сообщений: 4045
Роман Дынник


Тем что делается несколько вызовов и как следствие - старт транзакции на стороне среднего звена/клиента вместо того что бы стартануть на сервере с последующими возможными проблемы с deadlock-ми.
Как вам (100+1) вызов на сохранение счета со 100 позициями?


С уровнями изоляции если правильно работать - то никаких deadlock'ов не будет
21 дек 04, 11:13    [1195781]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
И почему-то все рассматривается со стороны разработчика клиента: мне программировать так удобно, я знаю ООП и больше ничего знать нехочу, всякие там PL/SQL, TSQL учить и знать не хочу да и ваще мне пофиг все эти БД - я же универсальный программист, к СУБД никакого отношения не имею зато смогу сделать под любую БД, у меня же объекты!!!
Почему-то забывают про админа/архитектора/разработчика БД, который потом, когда жареный петух клюнет, каким-то образом должен будет разгребать завал, пытаясь поднять производительность, построить индексы, поменять чего еще, если вообще это можно сделать.
А забывают зря. Может потому что не знают, что сделать клиента - это 30% дела, а сделать так, чтобы это все работало, да еще без затыков, быстро и т.д. и т.п. - остальная работа.

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

Откуда:
Сообщений: 3324
автор
Вы расскажите смысл представления данных как объектов? Я вот не вижу. И гораздо проще иметь набор таблиц с полями, с которыми можно сделать что угодно, которые являются родными по отношению к СУБД - и следовательно проще и быстрее их обрабатывать и т.д.

В Оракле вот давно есть возможность создавать пользовательские типы данных, с методами, свойствами... Ну и что, много кто ее использует, эту возможность?


А я и не говорил про создание пользовательских типов данных и ПОЛНОЙ реализации ООП в БД. Я наоборот против этого. Я говорил о способе мышления и как грамотно отразить классы на обычные таблицы с полями с привычними типами данных. Если отбросить среднее звено, клиента, и рассматривать одну лишь БД она НИЧЕМ не будет отличаться. Те же таблицы, типы данных, хп, вьюхи. Просто она будет более формализована, более прозрачна, ее модель будет более понимаема. Вообщем обычная база с таблицами в 3 НФ. Все что там присутствует от ООП - это всего лишь:
наследование в виде связи 1-1
методы в виде слоя хп
свойств и акцессоров get/set там нет и в помине, события... ну можно в первом приближении с большой натяжкой определить их как триггеры, но триггеры я вообще обычно не использую.

автор
Ну и опять же легкость поддержки системы - если у вас логика зашита в клиента и вам нужно чего-то изменить, но не в выводе информации для клиента, а именно часть бизнес-логики, то вам придется каждый раз компилять клиента и выкладывать пользователям. В случае же бизнес-логики на сервере, ничего никуда ненадо выкладывать - все меняется для всех прозрачно. Вы еще не почувствовали разницу? Может вы просто не пробовали сделать обычное приложение с обычной РСУБД? Попробуйте.

я почувствовал... когда в хп была зашита вся бизнес логика... начиная от проверки на допустимость ввода до выполнения cmdshell и вызовов COM. Сервак просто задыхался от выполнения таких процедур.
По поводу поодержки - разделяйте код на сборки, модули...
Про перенос БЛ на клиенте - я вообще к этому не призывал, я говорил что на клиенте должна ДУБЛИРОВАТЬСЯ проверка корректности ввода данных, это сокращает число повторных обращений к серверу (СУБД или к среднему звену или к веб серверу в случае если клиент - браузер, а проверка корректности ввода на JS).

>>tygra, вы вникайте повнимательнее в сообщения.
21 дек 04, 12:00    [1195987]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
andy st
Member

Откуда:
Сообщений: 906
Роман Дынник

Сейчас многие так и поступают, именно на РСУБД накладывают ООП, и это правильно, иначе при огромном количестве сущностей поддержка проекта превращается в сущий ад в котором может разобраться только "основной" разработчик.

ООП также ничем не упрощает поддержку систем.
а вот что сильно упрощает - так это хорошо комментированные исходники и нормальная документация. а ООП или не ООП подход был при разработке системы - это вторичное и совсем не самое критичное.
какая разница, что переписывать при добавлении входного параметра в процедуру: саму процедуру и все вызовы к ней при обычном подходе или метод и все его вызовы при ООП?
21 дек 04, 12:23    [1196134]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

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

Бизнес-логика. Так где же она? А то что-то в параллель топику про ООСУБД получилось ощущение, что вся БЛ на клиенте/среднем звене.
Лично у меня вся БЛ в СУБД, естественно за некоторым исключением или дополнением на клиенте в виде простейшего контроля ввода данных, типа ввели/неввели. Все, больше на клиенте ничего нет.

автор
А я и не говорил про создание пользовательских типов данных и ПОЛНОЙ реализации ООП в БД. Я наоборот против этого.

Тут я тоже против.
автор
Я говорил о способе мышления и как грамотно отразить классы на обычные таблицы с полями с привычними типами данных.

Зачем???????????? Кто такие классы? Зачем они?
автор
Если отбросить среднее звено, клиента, и рассматривать одну лишь БД она НИЧЕМ не будет отличаться. Те же таблицы, типы данных, хп, вьюхи. Просто она будет более формализована, более прозрачна, ее модель будет более понимаема.

Тогда смысл вашего ООП? Хотя как мне кажется, если в БД будут отражаться классы, то все-же не так будет понятно, как если бы структура была изначально сделана как обычно.
автор
Вообщем обычная база с таблицами в 3 НФ. Все что там присутствует от ООП - это всего лишь:
наследование в виде связи 1-1
методы в виде слоя хп
свойств и акцессоров get/set там нет и в помине, события... ну можно в первом приближении с большой натяжкой определить их как триггеры, но триггеры я вообще обычно не использую.

Зачем вам ООП в данных, ну не понимаю я. Я не вижу смысла городить огород с ООП над данными. если у меня и так все есть и я все могу сделать с данными без проблем. Мне бы пример какой, показывающий разницу :)

автор
я почувствовал... когда в хп была зашита вся бизнес логика... начиная от проверки на допустимость ввода до выполнения cmdshell и вызовов COM. Сервак просто задыхался от выполнения таких процедур.

Так с мозгами делать надо. И не пихать в СУБД то, чего там быть не должно. Можно и на клиенте все так сделать, что он и не запустится :))
автор
По поводу поодержки - разделяйте код на сборки, модули...

Какая разница? Все-равно если править в клиенте, то его придется копировать и перезапускать.
автор
Про перенос БЛ на клиенте - я вообще к этому не призывал, я говорил что на клиенте должна ДУБЛИРОВАТЬСЯ проверка корректности ввода данных, это сокращает число повторных обращений к серверу (СУБД или к среднему звену или к веб серверу в случае если клиент - браузер, а проверка корректности ввода на JS).

Ну да, но проверка корректности ввода данных может означать разные вещи.

автор
>>tygra, вы вникайте повнимательнее в сообщения.

Стараюсь. Сбивает мысли соседний топик про ООСУБД, елы-палы :))

======
И так. Пока что я никак не вижу смысла укладывать данные в ООП структуру.
Примеров пока не видел - поэтому больше ничего не могу сказать.

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

Откуда:
Сообщений: 3324
>>>Tygra's
Для примера, какие бы вы таблицы создали для простого
справочника клиентов с разделением на физические и юридические лица?
21 дек 04, 12:42    [1196251]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
to funikovyuri
автор
Тем что делается несколько вызовов и как следствие - старт транзакции на стороне среднего звена/клиента вместо того что бы стартануть на сервере с последующими возможными проблемы с deadlock-ми.
Как вам (100+1) вызов на сохранение счета со 100 позициями?

автор
С уровнями изоляции если правильно работать - то никаких deadlock'ов не будет

Да? Даже если на 99 вызове внутри одной транзакции стартующей на клиенте/среднем звене неожиданно пропадет соединение с сервером БД?
21 дек 04, 12:50    [1196284]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Роман Дынник

Рома, среди читающих этот топик, я среди тех кто полностью на вашей стороне. Просто думаю спорить об этом бесполезно (один тигра чего стоит :) )

Да? Даже если на 99 вызове внутри одной транзакции стартующей на клиенте/среднем звене неожиданно пропадет соединение с сервером БД?
Да - DEADLOCK'a не будет. Другой вопрос что приведенный вами пример относиться скорее не к вопросу выбора о том откуда управлять транзакциями (с клиента или с БД), а просто к типичной ошибке проектирования (решается с помощью всем известного патерна facade)
21 дек 04, 12:56    [1196330]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
кстати, незакоммиченные данные на блокировочнике можно перехватить через грязное чтение, правда все никак не дойдут руки, чтоб выложить как это делается.
21 дек 04, 12:58    [1196337]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
gardenman

далось, блин, это грязное чтение
21 дек 04, 13:06    [1196377]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Для примера, какие бы вы таблицы создали для простого
справочника клиентов с разделением на физические и юридические лица?

А прямо так, как у нас и сделано :)
Таблица Клиент, где все данные, относящиеся и туда и сюда: ФИО, мыло, дата, ... в общем, типа такого. И поле Юрлицо - если 0, значит нет, если 1 - значит это юрик, и тогда у него есть реквизиты =>
А это уже таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д.
Вот вроде и все. Когда мне нужен просто клиент - селект фром Клиент. Если нужны реквизиты к тому же - left join Реквизиты. Ну и т.д.
Как вы можете прокомментировать?

автор
Рома, среди читающих этот топик, я среди тех кто полностью на вашей стороне. Просто думаю спорить об этом бесполезно (один тигра чего стоит :) )

Да, уж поспорить то я люблю :)). Но тут не спор ради спора - просто хочу узнать, чем лучше или чем хуже данная реализация.
Т.к. основные действия (да и почти все вообще) над данными производятся в БД, то какой смысл как-то специально менять их структуру для представления на клиенте?

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

"Выложу" для MS SQL, так и быть :)
select * from table [b]with(nolock)[/b]

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

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Кстати, вспоминая про "весомые плюсы". Источник:

OTN: Can you tell us more about Oracle Developer Tools for Visual Studio .NET and Oracle Database Extensions for .NET?

Datta: Oracle joined the Microsoft Visual Studio Industry Partner (VSIP) program as a Premier Level Partner in May 2004 and we have been working very actively on developing Oracle Developer Tools for Visual Studio .NET. Oracle Developer Tools is a tightly integrated tool set within Visual Studio .NET to enable developers to use the power of the Oracle Database easily and effectively. With this tool set, Windows developers do not need to learn any new tool and can remain in Visual Studio environment throughout a project's lifecycle.

Oracle Developer Tools for Visual Studio .NET will support Oracle schema browsing and modification, wizards and designers, automatic code generation, an integrated help system, a PL/SQL editor, and many other features. A Beta release of the tool set will be available by the end of 2004. A production release is slated for the first quarter of 2005.

Oracle Database Extensions for .NET allow development and deployment of .NET based stored procedure in the Oracle Database. Stored procedures can be in VB.NET, C# or C++, and the deployment is supported from within Visual Studio environment. Stored procedures can use the server-side ODP.NET for interacting with the database. This release will be available in the first half of 2005.

OTN: What are the differentiators for Oracle in .NET environment?
"Oracle Application Server supports many features for integration with Windows and .NET."

Datta: Oracle Application Server supports many features for integration with Windows and .NET: I'll just go through a mental list, highlighting some features as I go.
The first that comes to mind is Windows Single Sign-On. Once a user is logged on to Windows, no further credentials are required. We also provide Active Directory integration, which extends user identity management through Oracle Internet Directory and the Oracle Identity Management infrastructure. Then there's Microsoft IIS support, where even though an application is developed for Oracle Application Server, it can still use Microsoft IIS as a Web server. We further extend integration through Oracle Portal, to aggregate Microsoft content, such as that from Exchange, and then wireless-enable it. Message exchange is also possible with Biztalk Server, ensuring business process integration.

Other integration has been done with Microsoft Cluster Services, providing high-availability for the Oracle Application Server infrastructure. We also offer interoperability with the use of Web Services, where interoperability with .NET applications and services are key features. Then there's WebDAV integration, which allows Windows desktop or Windows applications such as Explorer or Office to interoperate with those developed using Oracle Application Server.

Finally, we provide things such as Oracle Web Cache for improving the performance of ASP applications; a database adapter for SQL Server, where interoperability is enabled from Oracle Application Server to SQL Server; and Windows CE-based device support for mobile applications, where a broad range of Windows-compatible devices for individual and enterprise applications are enabled.
21 дек 04, 13:53    [1196640]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
Таблица Клиент, где все данные, относящиеся и туда и сюда: ФИО, мыло, дата, ... в общем, типа такого. И поле Юрлицо - если 0, значит нет, если 1 - значит это юрик, и тогда у него есть реквизиты =>
А это уже таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д.
Вот вроде и все. Когда мне нужен просто клиент - селект фром Клиент. Если нужны реквизиты к тому же - left join Реквизиты. Ну и т.д.
Как вы можете прокомментировать?


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

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

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

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

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

Откуда: Moscow
Сообщений: 2406
(Роман Дынник) >>
тбл. Контрагент (id,краткое наименование, инн)
тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование)
тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование)
==

Всё-таки плохо, что можно завести контрагента, который будет ни физическим, ни юридическим лицом.
21 дек 04, 14:03    [1196691]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
Я бы сказал, что контагент - это обобщение понятия физических и юридических лиц. То есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо.
21 дек 04, 14:05    [1196695]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Роман Дынник

В ER-нотации есть отношение generalization - так что при желании и знаниях решение будет в точности соответствовать предложенному
21 дек 04, 14:10    [1196726]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
www.fun4me.narod.ru
Всё-таки плохо, что можно завести контрагента, который будет ни физическим, ни юридическим лицом.

А кто сказал, что его можно завести? Для этого в 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контрагент

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

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

select * from v$contractors
select * from v$phpersons
select * from v$organizations

То есть - постоянные join-ы стоит прятать во вьюхи (естественно, не забывая об эффективности). Во всяком случае, наличие в 50 различных запросах фразы "[Юридическое лицо] JOIN [контрагент]" меня серьезно насторожит.
21 дек 04, 14:15    [1196748]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
Я бы сказал, что контагент - это обобщение понятия физических и юридических лиц

Именно это я и хотел сказать.
Всё-таки плохо, что можно завести контрагента, который будет ни физическим, ни юридическим лицом
Это уже бизнеслогика.
автор
То есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо.

Это как? т.е. в контрагенте у вас будет 2-а поля одно из которых ссылается на ф/л, другое на ю/л? Это не правильно.
21 дек 04, 14:17    [1196755]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Shtock
Member

Откуда: СПб
Сообщений: 3049
Господа, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем...
21 дек 04, 14:17    [1196759]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить