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

Откуда: 127.0.0.1
Сообщений: 67393
Блог
Yo!
есть неоспоримый факт что существует достаточно большая часть программеров

Этот баян мы недавно обсуждали...
10 дек 04, 16:17    [1174686]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
c127
Guest
2 ASCRUS

>Мне вот интересно другое - MS же должна понимать, что развязывая руки кодерам в MSSQL и давая им такое мощное средство, как C# и CLR, она просто ставит под удар такие характеристики, как надежность, скорость и безопасность. Уже видны толпы радостно потирающих руки кодеров, с высказываниями типа - "Наконец то мы в БД все реализуем как привыкли в Access/Delphi/etc". Исходя из этого можно ожидать на сегменте баз данных MSSQL необычайно мощного всплекса криво реализованных БД, собственных велосипедов обработки и хранения данных в БД (вот уж где будет соблюдение "одного стандарта программирования"), вирусов хранимых-процедур и много чего еще интересного.

Не беспокойтесь, ничего не изменится. Посмотрите на Ваш же пример:

SqlCommand cmd = SqlContext.GetCommand();
cmd.CommandText = "select intcolumn from tbl";
SqlDataReader r = cmd.ExecuteReader();


На каждый чих (select, insert, update) - 3 строчки. Синтаксис запроса на этапе компиляции никак не проверяется. Так много не напишешь. Так что получится то же, что и с джавой в других SQL серверах: поиграются и вернуться к TSQL. Это кто поумнее и кому нужно работу делать, а кто попроще будут бороться с C#.
11 дек 04, 03:17    [1175893]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
g
Guest
большинство высказываний защитников ORACLЕ находиться на уровне эмоций: SQL-Server - отстой,
а Б. Гейтс - козел по определению, следовательно пользоваться его продуктами не будем, а кто
пользуется - лохи позорные.

Видали мы таких - рвут глотку, что винда - тормозная и незащищенная по сравнению с *nix , а сами
с ХР не слазят.

Если вы привыкли к oracle и не хотите пользоваться MSSQL, которая по сути не лучше и не хуже,
так честно так и скажите, а не наезжайте на новые возможности системы, только потому, что
ненавидите microsoft.
11 дек 04, 15:39    [1176083]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Ну кто сказал что мы ненавидим M$? В принципе - хорошая ОС. Но вот политика M$ в области продвижения своего ПО не всегда чистоплотна (хотябы в отношении Линукс). У ПО от M$ полно недостатков, в некоторых аспектах оно хуже и отстает от ПО других производителей, которые разрабатывают софт на их же платформе. Конечно же M$ никуда не денется ближайшие годы, но однако потесниться придется, причем основательно.
Время покажет.
--
Да здравствует Линукс!
11 дек 04, 16:47    [1176116]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
c127
Guest
2 g

>большинство высказываний защитников ORACLЕ находиться на уровне эмоций: SQL-Server - отстой, а Б. Гейтс - козел по определению, следовательно пользоваться его продуктами не будем, а кто пользуется - лохи позорные.

Это аргументированно, с выдержками и цитатами и без лишних эмоций.
12 дек 04, 00:34    [1176446]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
gardenman
Конечно же M$ никуда не денется ближайшие годы, но однако потесниться придется, причем основательно.
Время покажет.

Дык время то вроде как раз наоборот показывает - MS остальных теснит :)
12 дек 04, 01:24    [1176460]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
g
Guest
2 c127

Мимопроходящий

Visual Basic форева!!!!
Ураааа!!!
Заменим Басиком SQL !!!!
Ураааа 2 раза!!!




nik_x
Не доконца мысль излил...
Ударим Пивом по M$-рожью и разгильдяйству !!!



Yo!
мда .. меняем mssql на mysql а оракл на mssql и понимаем какую чушь пороли :)


ЗЫ. mssql это пока единственная субд добившееся действительно впечатляющих результатов в области секурити - это единственая субд с вирусами на пару дней вывела из строя целый регион. такое еще никому не удавалось.


nik_x

Ну а насчет PL/SQL, коль не дошло, то:
ПЛОХОМУ ТАНЦОРУ - ЯЙЦА МЕШАЮТ !



Достаточно ?


2 gardenman

Если кто не знает, то Unix появился много раньше Windows. Его первая версия вышла аж в 1971 г., и
в свое время он (и его разновидности) доминировали в мире.
Windows существует только около 10 лет (не считая 3.1), и является абсолютным лидером все эти 10 лет.
То-же самое касается ДОС, который был ВЕЗДЕ.
Так что Microsoft никуда не денется, Linux конечно тоже в небытие не впадет, но и в лидеры никогда
не выбьется. Да и что такого там с ценовой политикой ? Посмотрите сначала сколько стоит Red Hat Linux,
а людей, которые сами скачивают бесплатные дистрибутивы и компилят их, не так много, я например себе
занятие поинтереснее найду.
12 дек 04, 11:48    [1176577]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Yo!
Guest
2g

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

Откуда:
Сообщений: 3001
g - забудте в этой ветке про Linux. На данный момент обсуждаемые СУБД имеют свои излюбленные платформы MSSQL - Win2k, 2k3 Oracle = unix(solaris, ..). Oracle на Linux держат в 99% для тестовых систем. А тот же Solaris не такая пионерская разработка, как Вы пытаетесь нам преподнеси.
12 дек 04, 18:48    [1176850]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
hell

Oracle на Linux держат в 99% для тестовых систем.

Наша фирма начала ставить закачикам Оракл на Linux. Т.е. раньше были видны, но при установке новой версии инф. системы ставят Linux. Ну и для разработки на фирме 2 сервера на Linux, Один старый на Виндах. Правда много ораклов на клиентских компах на виндах - потому, что на серваке возникают неприятные накладки - один снес что-то из БД, а там были разрабатываемые объекты коллеги (у нас несколько разных проектов). У заказчиков для БД Одна Open VMS, один UNIX - это требования заказчика. Один заказчик раньше перешел с UNIX на Винды из-за того, что передали систему для администрирования тамошним АСУ-бщикам, а те не знают UNIX и потредовали перевода на Винды серверов. Хорошо, что Ораклу по барабану ОС. Конечно, если не обращать внимания, что там свои баги могут быть. Но вроде пока не напрягает.
12 дек 04, 20:29    [1176892]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
vadiminfo
hell

Oracle на Linux держат в 99% для тестовых систем.

Наша фирма начала ставить закачикам Оракл на Linux. Т.е. раньше были видны, но при установке новой версии инф. системы ставят Linux. Ну и для разработки на фирме 2 сервера на Linux, Один старый на Виндах. Правда много ораклов на клиентских компах на виндах - потому, что на серваке возникают неприятные накладки - один снес что-то из БД, а там были разрабатываемые объекты коллеги (у нас несколько разных проектов). У заказчиков для БД Одна Open VMS, один UNIX - это требования заказчика. Один заказчик раньше перешел с UNIX на Винды из-за того, что передали систему для администрирования тамошним АСУ-бщикам, а те не знают UNIX и потредовали перевода на Винды серверов. Хорошо, что Ораклу по барабану ОС. Конечно, если не обращать внимания, что там свои баги могут быть. Но вроде пока не напрягает.


Это как это много оракла на клиентских компах? Каждому разработчику по базе что-ли? Для тестирования и сборки релизов у вас должна быть отдельная база, где у разработчиков прав нет.
12 дек 04, 20:41    [1176898]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
killed

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

На клиентских для разработки своих задач. Но там по одной-две БД. Не у всех разработчиков конечно. А у меня так еще и дома. На серверах несколько БД по разным проектам. Например, эти празники для тестирования и настроек закчиваю в одну такую в две таблы по 30 миллионов записей. Конечно, такого на клиентском компе нет возможности провернуть. Кроме того, мы и есть разработчики - т.е. и разработчики БД. К сожалению, у заказчика реализовали уже кластер с рейдами, а этого нет сейчас на фирме. Те кто проектировали торопились или что (не дотестировали), но теперь там у заказчика что-то тормозит, а мне дали задание решить этот вопрос. Так что тестирование идет не на полном аналоге. Т.е. у нас много баз для тестирования, а той что надо (в плане физической реализации) для выполнения моего задания нет. Возможно, придется еще ехать самому к заказчику и там разбираться, а очень неохота, и денег фирмы жалко (итак этим летом не было большой премии).
Одно дело, то что в книгах написано про то как должно быть, а другое то с чем приходится сталкиваться в реальности.
12 дек 04, 21:36    [1176948]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
vadiminfo
killed

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

На клиентских для разработки своих задач. Но там по одной-две БД. Не у всех разработчиков конечно. А у меня так еще и дома. На серверах несколько БД по разным проектам. Например, эти празники для тестирования и настроек закчиваю в одну такую в две таблы по 30 миллионов записей. Конечно, такого на клиентском компе нет возможности провернуть. Кроме того, мы и есть разработчики - т.е. и разработчики БД. К сожалению, у заказчика реализовали уже кластер с рейдами, а этого нет сейчас на фирме. Те кто проектировали торопились или что (не дотестировали), но теперь там у заказчика что-то тормозит, а мне дали задание решить этот вопрос. Так что тестирование идет не на полном аналоге. Т.е. у нас много баз для тестирования, а той что надо (в плане физической реализации) для выполнения моего задания нет. Возможно, придется еще ехать самому к заказчику и там разбираться, а очень неохота, и денег фирмы жалко (итак этим летом не было большой премии).
Одно дело, то что в книгах написано про то как должно быть, а другое то с чем приходится сталкиваться в реальности.


Если честно, это все малоубедительно. По-моему опыту, чем больше исключений из правил - тем больше хаоса при разработке. А еще я убежден, что грамотный разработчик, если он считает себя профессионалом, будет работать в рамках общего полиси, не изобретая велосипед. Почему? Потому что он знает, что съэкономит себе массу времени. Другое дело, когда такого полиси нет у компании, но это уже ваша вина.

По поводу rac, raid и т.д. А откуда уверенность, что проблема именно в "физике"? Это мне кажется вообще аутскоп для разработчиков. Я бы к примеру для начала попросил клиента выслать экспортированную статистику. Применить ее на базе (опять таки на базе для целей QA) и протестировать функционал. В любом случае, сделать "полный аналог" - имхо нереальная задача.
12 дек 04, 22:04    [1176963]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
killed

Если честно, это все малоубедительно. По-моему опыту, чем больше исключений из правил - тем больше хаоса при разработке. А еще я убежден, что грамотный разработчик, если он считает себя профессионалом, будет работать в рамках общего полиси, не изобретая велосипед. Почему? Потому что он знает, что съэкономит себе массу времени. Другое дело, когда такого полиси нет у компании, но это уже ваша вина.

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

killed

По поводу rac, raid и т.д. А откуда уверенность, что проблема именно в "физике"? Это мне кажется вообще аутскоп для разработчиков. Я бы к примеру для начала попросил клиента выслать экспортированную статистику. Применить ее на базе (опять таки на базе для целей QA) и протестировать функционал. В любом случае, сделать "полный аналог" - имхо нереальная задача.



Я имел в виду, что если бы тестирование было один к одному, то я бы чувствовал себя более уверенно. Я бы проверил те исправления на реальном варианте, и их бы выполнили удаленно или те кто туда ездит. А так может не повезти и там окажется что-то другое. Может и не с Ораклом связанное, наряду с причинами Оракловыми. Например, что-то левое ресурсы хапает. То что физика играет роль для тестирования достойно учета. Например, уже есть показания перенести журналы повторного выполнения лучше на другой диск на этом серваке, а там рэйды и таких ожиданий может и не быть. Там показатели I/O другие - много выше. Конечно, все что касается приложения будет проверено, но пойдут ли на исправления не известно. Например, уже есть подозрения на чрезмерные коммиты.
Что касается статиситки, то ее сбор там еще надо организовать. Кроме того, для выявление конкретных причин нужно отлавливать чего ожидает сессия в момент, когда тормоза явно видны. Ну и все такое. Возможно все это придется сделать (там организовывать сбор статистики и ждать когда тормознется), после того как въеду в особенности работы БД в этом проекте.
Но очень хочется, чтобы обошлось без этого.
12 дек 04, 23:49    [1177006]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
c127
Guest
2 g

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

Вполне нормальные аргументы, если не лениться читать. Я тоже объяснил почему считаю что C# в качестве языка программирования SQL серверов не приживется. Хранение запросов в виде строк с проверкой синтаксиса и пр. во время исполнения работает только когда таких запросов относительно немного. На SQL серверах запрос - основное средство работы, строк с запросами чуть ли не больше, чем строк без запросов. Кроме того еще, предлагается увеличить это количество втрое. Поэтому должен быть специализированный язык или хотя бы препроцессор как у ДБ2, оракла и сайбейза, а джава или C# для этой задачи неудобны.
14 дек 04, 02:28    [1178369]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
Надо для СУБД вместо CLI использовать какой-нибудь DPLI /*Data Processing Lanuage Infrastructure*/, который должен быть расширнием CLI и в которм будут хранится разобранные запросы. Тогда быстро работать всё будет. А если DPLI подключить к Mono и присобачить к MySQL, то хранимые процедуры будут переносимы.
14 дек 04, 08:43    [1178472]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
позвольте и мне пару ложек.
Вот тут мнения такие наблюдаются:

автор
Зачем перегружать СУБД излишней бизнес-логикой, для этого есть сервера приложений...

Правильно, незачем ИЗЛИШНЕЙ перегружать, но существует огромное количество примеро в которых java stored procedure намного удобнее чем PL/SQL- вариант.
Возьмем ORDER/Detail.
Что бы сохранить счет оптимальным способом (одним вызовом):
1) для PL/SQL варианта понадобиться сериализовать объект в xml, вызвать sp на PL/SQL, там "разобрать" xml и сделать соответствующие инсерты в мастер и деталь.
2) для варианта с java вы работаете в терминах объектов и на стороне клиента, и на стороне сервера приложения и на стороне сервера СУБД.
Поэтому если у вас плоский объект, возможно выбор будет в пользу PL/SQL, если же иерархический - то он прямой кандидат для реализации CRUD- операций на java.

Т.е. я что хочу сказать? То, что никто никогда не убеждал никого в том что перенос ВСЕЙ бизнес логики на сервер СУБД есть хорошо.
Но вот перенос бизнес-логики относящейся к CRUD-операциям на сторону СУБД безусловно способствует и пониманию того как работает база, и сокращению сроков разработки (в случае использования java на стороне СУБД), и сопровождению.
Так что поддержка .NET в mssql - это шаг в правильном направлении, который даст получить схожие возможности по сравнению с существующими СУБД с поддержкой Java.

автор
Java мешается под ногами, PL/SQL вполне достаточен для реализации бизнес-логики на сервере.

Ничего она (Java) не мешается, Oracle-у уж точно :), а что касается Sybase дык писать нужно лучше чтоб под ногами java не мешалась.
И еще... как думаете почему в Oracle Lite процедуры и триггеры можно писать только на Java и никакого PL/SQL там нет?
Громоздок он слишком оказался для встраивания в мобильные СУБД (видимо)...

Относительно YUKON-а могу лишь надеяться на то, что дай бог нам получить хотя бы такую же функциональность/возможности которые есть в ORACLE 8i.
Так что ВЕСОМЫЙ под сомнением.
20 дек 04, 13:58    [1193372]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Роман Дынник
Возьмем ORDER/Detail.
Что бы сохранить счет оптимальным способом (одним вызовом):
1) для PL/SQL варианта понадобиться сериализовать объект в xml, вызвать sp на PL/SQL, там "разобрать" xml и сделать соответствующие инсерты в мастер и деталь.
2) для варианта с java вы работаете в терминах объектов и на стороне клиента, и на стороне сервера приложения и на стороне сервера СУБД.
Поэтому если у вас плоский объект, возможно выбор будет в пользу PL/SQL, если же иерархический - то он прямой кандидат для реализации CRUD- операций на java.

Ооопс. А вот для варианта 2 (java) внутри логика разве не будет как и варианте 1 разбирать переданный для расширенной ХП обьект по косточкам и делать соотвествующие инсерты/апдейты в мастер и детайл ? А чем не устраивает стандартно для клиента открыть транзакцию, записать мастер, записать детайл, подтвердить транзакцию ? Ну а если даже уж хочется оптимальным (?) способом, то кто мешает сделать такую ХП:
CREATE PROCEDURE sp_Master_Detail_Insert_Update (
  IN @xml xml
)
BEGIN
  INSERT INTO master ON EXISTING UPDATE WITH AUTO NAME
    SELECT *
    FROM OPENXML(@xml, '/master')
    WITH (
      id_master int '@id_master', 
      name char(50) '@name'
    );

  INSERT INTO detail ON EXISTING UPDATE WITH AUTO NAME
    SELECT *
    FROM OPENXML( @xml,'/master/detail')
    WITH (
      id_master int '../@id_master', 
      id_detail int '@id_detail', 
      value int '@value'
    );
END;
Теперь клиент спокойно может одним вызовом заносить данные:
CALL sp_Master_Detail_Insert_Update ('
  <master id_master="1" name="Test record">
    <detail id_detail="1" value="100"/>
    <detail id_detail="2" value="200"/>
    <detail id_detail="3" value="300"/>
  </master>
');
Так же при желании на эту процедуру можно сделать веб-сервис и использовать его в HTTP протоколе или SOAP. Плюс можно даже в другой удаленной СУБД ее организовать как удаленную процедуру вызовом через стандартные инет-протоколы:
CREATE PROCEDURE sp_Master_Detail_Insert_Update ( @XML xml )
URL 'HTTPS://HostName/service_Master_Detail_Insert_Update'
TYPE 'SOAP:RPC'
Как видно и без Java мы прекрасно работаем с XML, веб-сервисами и любыми нужными нам фичами.

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

Дык мы и стараемся на Sybase писать так, чтобы Java родимая не мешалась, пользуясь только стандартными и неплохими возможностями WatcomSQL, без загрузки сервера кушающей память JVM :)
20 дек 04, 16:15    [1194116]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
А чем не устраивает стандартно для клиента открыть транзакцию, записать мастер, записать детайл, подтвердить транзакцию ?

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

автор
Ну а если даже уж хочется оптимальным (?) способом, то кто мешает сделать такую ХП:

Никто не мешает, я же об этом и говорил. И сам xml активно пользую.
Но XML вы этот как получите? Нужно на стороне клиента сеарелизовать java-объект или вручную по объекту собрать XML, правильно? А в случае java-процедуры вы передаете объект без всяких усилий со стороны кода клиента.
И второе повышается читабельность кода на стороне СУБД а следовательно и качество поддержки, но это уже на вкус.
20 дек 04, 16:43    [1194250]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
JVM кушает 50М
для нормального сервака - это копейки.
20 дек 04, 16:48    [1194278]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>>Никто не мешает, я же об этом и говорил. И сам xml активно пользую.
Но XML вы этот как получите? Нужно на стороне клиента сеарелизовать java-объект или вручную по объекту собрать XML, правильно? А в случае java-процедуры вы передаете объект без всяких усилий со стороны кода клиента.
<<


В .NET через SOAP объекты точно так же передаются абсолютно без всяких усилий со стороны разработчика клиентского приложения. А объект по любому сериализовать придётся - что при передаче через RMI, что при передаче через SOAP.
20 дек 04, 16:58    [1194310]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
В .NET через SOAP объекты точно так же передаются абсолютно без всяких усилий со стороны разработчика клиентского приложения.
Тут пока про яву шорох поднялся.
автор
А объект по любому сериализовать придётся - что при передаче через RMI, что при передаче через SOAP.

Мы говорим не про автоматическую/полуавтоматическую сериализацию (в случае .NET) через SOAP или RMI а про передачу объекта в процедуру через "строковый" параметр XML. Вот чтоб в этот строковый параметр значение(объект в виде XML) запихнуть и нужны усилия со стороны разработчика.
20 дек 04, 17:13    [1194385]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Роман Дынник
Мы говорим не про автоматическую/полуавтоматическую сериализацию (в случае .NET) через SOAP или RMI а про передачу объекта в процедуру через "строковый" параметр XML. Вот чтоб в этот строковый параметр значение(объект в виде XML) запихнуть и нужны усилия со стороны разработчика.

Минуточку - так я и привел пример процедуры в СУБД, которая элементарно превращается в SOAP-процедуру, с которой клиентское приложение может работать через тот же 80 порт на получение и передачу данных, вообще не используя никаких ODBC, JDBC, ADO.NET и прочего. А с клиентских приложений по моему все кому не лень могут с XML и веб-сервисами работать.
20 дек 04, 17:22    [1194426]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
через тот же 80 порт

работа с сервером ч/з HTTP/S - это еще одна ОЧЕНЬ длинная песня, тут можно и про безопасность тему развить и производительность сравнить и про целесообразность погорорить...

Я еще пример приведу. Допустим для какого то класса у вас глубина наследования равная 5.
Соответственно на сервере, если CRUD в слое хп вам надо выполнить:
sp_Ins5(@xml)
-sp_Ins4(@xml)
-sp_Ins3(@xml)
-sp_Ins2(@xml)
-sp_Ins1(@xml)
т.е. из хп5 вызывается хп4, из хп4 - хп3 и т.д. до 1-го уровня
и в каждой процедуре делать OPENXML. Как вы думаете, с производительностью все нормально будет?
20 дек 04, 17:54    [1194596]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Роман Дынник
автор
через тот же 80 порт

работа с сервером ч/з HTTP/S - это еще одна ОЧЕНЬ длинная песня, тут можно и про безопасность тему развить и производительность сравнить и про целесообразность погорорить...

Я еще пример приведу. Допустим для какого то класса у вас глубина наследования равная 5.
Соответственно на сервере, если CRUD в слое хп вам надо выполнить:
sp_Ins5(@xml)
-sp_Ins4(@xml)
-sp_Ins3(@xml)
-sp_Ins2(@xml)
-sp_Ins1(@xml)
т.е. из хп5 вызывается хп4, из хп4 - хп3 и т.д. до 1-го уровня
и в каждой процедуре делать OPENXML. Как вы думаете, с производительностью все нормально будет?

Ну во первых кто мешает вызывать просто sp_Ins5(@xml), передавая туда сразу все аттрибуты класса и его предков ? Во вторых Вы пытаетесь на РСУБД наложить ООП, а при моем подходе это просто ни к чему. Зачем спрашивается на уровне клиента плодить бизнес-классы, если вся бизнес-логика лежит на СУБД и от клиента требуется ума только получить данные в виде набора данных, показать их для просмотра, организовать их отложенное изменение и потом пакетно сохранить все изменения ? Для организации такой работы в любой среде построения клиентов сейчас существуют стандартные компоненты доступа к данным, их визуального просмотра и построения отчетов. Этого вполне достаточно, чтобы организовать клиента в виде GUI приложения или интернет-проекта. В данном случае по моему личному мнению ООП будет использоваться по прямому его назначению - быстрой организации и легкой поддержки интерфейсной части. Всякие попытки перенести бизнес-обьекты на классы и потом танцевать с бубном по проведению их хранения и эффективности обработки на РСУБД только усложняют задачу. В конце концов при автоматизации какой то задачи у нас нигде в постановке нет задания создать аналог реального отображения обьектов. Нам всего то нужно обеспечечить хранение и обработку информации (именно информации, а не обьектов), где лучше всего подходят РСУБД и организовать удобный интерфейс работы с пользователем, где ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения. И тут, как только мы данные РСУБД начинаем рассматривать именно как информацию, а не понятно для чего нужные обьекты, все становиться на свои места. Плюс не понятно, что именно должно наследоваться в бизнес-обьектах - если какие то аттрибуты и логику сущностей можно выделить единым целым, то на "Один-ко-Многим" это все прекрасно реализуется по таблицам, триггерам, представлениям и хранимым процедурам по нормальным формам. Так что лично для меня понятия "Сущности-Аттрибуты" гораздо лучше ложаться на ТЗ поставленных задач, чем "Классы-Обьекты-Свойства". Единственный существенный недостаток, присущий кстати как РСУБД, так и ООП - это строгая формализация данных, где в обоих случаях поддержка обьектов с неизвестным заранее кол-вом аттрибутов будет стоить дополнительных усилий в проектировании и реализации эффективной работы. Опять же мое личное мнение - для этого необходимо вообще разделять данные и код бизнес-логики, причем данные должны быть структурами с произвольным набором аттрибутов определенных в словаре доменов, а бизнес-логика оперировать такими структурами с подходящими по наличию доменов и их значений (где опять же создаются расширяемые словари глаголов по принципам работы функциональных языков) и связывающим звеном для манипуляции множествами является язык запросов. В данном случае очень похоже на продвижение формата XML, хотя куда он двинется и что из этого получится пока не понятно :)
20 дек 04, 19:48    [1194915]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить