Зачем нужны многозвенки ?

← →
Anatoly Podgoretsky © (2005-11-01 10:06) [80]

ANB © (01.11.05 09:57) [79]
Не знаю как сейчас, но на старых Ораклах об ANSI не приходилось говорить, там же даже [*] JOIN не был поддержан.
А как сейчас с этим у Оракла?

← →
Juice © (2005-11-01 10:15) [81]

Курдль © (31.10.05 13:00) [62]

> Reindeer Moss Eater © (31.10.05 12:37) [58]
> Здесь никто и не говорит что многозвеньевые системы - это
> ацтой.

Я говорю, что это ацтой. Но иногда без него не обойтись.

Меня, как автора вопроса, интересовало именно это "иногда". Коллеги, приведите лучше примеры ситуаций когда без многозвенки просто не обойтись! И на чем по вашему мнению их лучше создавать - CORBA, DataSnap или что-то VS-нетовское? Слышал, что используя .NET многозвенки пишутся НАМНОГО быстрее и качественнее. Это так или просто маркетинг?

← →
Reindeer Moss Eater © (2005-11-01 10:25) [82]

Вот пример из личного опыта.
Необходимо предоставить клиенту доступ к данным распределенным по корпоративной филиальной сети.
Клиент не должен заморачиваться с вопросом где какой сервер находится, клиент должен соединившись с одним сервером приложений получить нужные данные. При написании не использовалась ни одна из перечисленных выше технологий.

← →
Курдль © (2005-11-01 10:25) [83]

> Juice © (01.11.05 10:15) [81]
> Меня, как автора вопроса, интересовало именно это "иногда".
> Коллеги, приведите лучше примеры ситуаций когда без многозвенки
> просто не обойтись! И на чем по вашему мнению их лучше создавать
> - CORBA, DataSnap или что-то VS-нетовское? Слышал, что используя
> .NET многозвенки пишутся НАМНОГО быстрее и качественнее.
> Это так или просто маркетинг?

Готов забожиться, что круче, чем "VS-нетовское" я еше не видел!
Изучите книжку "Microsoft .NET Remoting" (Скотт Маклин, Джеймс Нафтел, Ким Уильямс) и вопросов не будет.

← →
Juice © (2005-11-01 10:37) [84]

> Изучите книжку "Microsoft .NET Remoting" (Скотт Маклин,
> Джеймс Нафтел, Ким Уильямс) и вопросов не будет.

Оно и было, вспомнил. Штука действительно волшебная судя по описанию. Но все таки скажите свое веское слово в сторону DataSnap, стоит ли тратить время и практиковаться в ней или нет ? Думаю что нет, но хочу услышать подтверждение своим словам. Этим я закрою для себя тему "технологии Borlanda", не в том плане что забью на них :) а просто наконец-таки все станет на свои места - что когда и в каких случаях использовать.

← →
Курдль © (2005-11-01 10:52) [85]

> Но все таки скажите свое веское слово в сторону DataSnap

К сожалению не могу сказать от себя, т.к. не работал с ней. Но мои коллеги, которые работали с DataSnap, ни в какое сравнение с .NET Remoting ее не ставят.
Лучше я скажу свое слово в сторону .NET Remoting.
С ее помошью можно создать весьма эффективную распределенную систему, даже не углубляясь в ее изучение, а используя примеры на уровне "Hello? World!"
Основа ее идеологии - создание объекта (класса), который реализован и "установлен, активирован..." на одном домене, а используется приложениями на других доменах (компах, хостах и т.п.).
Т.е. описываете класс с методами типа FillSubjectsDataSet(out DataSet ds)
так, что в его теле происходит доступ к БД (это сторона сервера приложения).
А со стороны клиента вызываете эти методы "как родные".
Т.е. вызов со стороны клиента метода навроде RemoteObject1.FillSubjectsDataSet(out ds); вернет датасэт ds, заполненный нужными данными. (А датасэты в .NET - многотабличны и включают в себя релэйшны и констрэйнты).

← →
Курдль © (2005-11-01 13:11) [86]

> ANB © (01.11.05 09:57) [79]
> Трехзвенка в этом все равно не помошник. SQL у оракла и
> MS SQL настолько разный (особенно хранимок), что чтобы обеспечить
> совместимость хотя бы на уровне запросов, придется перейти
> на ANSI и жестоко потерять в производительности и возможностях.

Это что за догма про потерю производительности?
Зачем нужны ХП, если бОльшую часть работы по защите целостности данных в процессе их ввода, модификации и удаления берет на себя ADO.NET? Насчет триггеров еще можно поспорить, но без ХП отлично работается!

← →
TohaNik © (2005-11-01 13:56) [87]

> А датасэты в .NET - многотабличны и включают в себя релэйшны
> и констрэйнты

Может у меня мозги уже высохли, но толку от многотабличности не увидел.
А связи и ограничения - так за ними и так база следит

> Зачем нужны ХП, если бОльшую часть работы по защите целостности
> данных в процессе их ввода, модификации и удаления берет
> на себя ADO.NET?

Как по мне, так защищать как то надежней средствами самой базы, ну а если с нервами не в порядке так еще и в приложении можно затычек наставить:).

Все ИМХО - .NET этот только пощупал и расстроился, один фиг само не кодится :(
:)

← →
ANB © (2005-11-01 14:06) [88]

> Зачем нужны ХП, если бОльшую часть работы по защите целостности
> данных в процессе их ввода, модификации и удаления берет
> на себя ADO.NET?

Может это и справедливо для MS SQL, т.к. T-SQL довольно ограниченная штука и на клиенте(сервере приложения) многое проще реализовать (ИМХО). Однако на PL/SQL реализуют полностью логику бизнес приложений, используя в качестве клиента обычный браузер. Плюс - хранимки в оракл таки быстрее клиентской обработки.

← →
Курдль © (2005-11-01 15:30) [89]

> TohaNik © (01.11.05 13:56) [87]
> Может у меня мозги уже высохли, но толку от многотабличности
> не увидел.
> А связи и ограничения - так за ними и так база следит

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

> Как по мне, так защищать как то надежней средствами самой
> базы, ну а если с нервами не в порядке так еще и в приложении
> можно затычек наставить:).

А защиту целостности базы никто и не отменял! Но для этого вполне достаточно правильной структуры БД и в сложных местах - парочку-тройку триггеров.

← →
ANB © (2005-11-01 16:28) [90]

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

Хочу .Net !!!. Вообще то гуляла у меня мысля занятся этим в делфи. Но если .Net так крута, то зачем изобретать велосипед. Хотя берут меня жмуткие сомнения, что это все корректно работает и без ручного программирования. Иначе зачем бы народ покупал дорогущий Oracle Application, в котором без ручного программирования все равно не обойтись ? Все имхо.

← →
Val © (2005-11-01 16:31) [91]

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

← →
Курдль © (2005-11-01 16:41) [92]

> ANB © (01.11.05 16:28) [90]

Без ручного программирования - никак! Я этот пример про трехзвенку прям с открытого проекта привожу. Точнее с решения (solution), которое включает 11 проектов (около 4000 файлов). Но в VS это настолько запросто живет и поддерживается, что не замечаешь масштабности.
Однозначно скажу, что есть предел глобализации проекта, когда уже усложнять невозможно - все рушится, друг с другом не согласуется, конфликтует и т.п.
У Делфей этот порог гораздо ниже.
А на "Oracle Application, forms, discoverer..." или на САП любят себя автоматизировать крупные монстроидальные корпорации. Во-первых, бабло удобно списывать, во-вторых - штат невдолбенно дорогих спецов "из своих" прикармливать и понты бросать. Есть предубеждение, что на "полупрограммируемых полуфабрикатах" типа перечисленных или даже совсем убогонькой 1С, поддерживать и совершенствовать систему проще. Типа "не в исходниках копаться, а модулями ворочать и скрипты подстраивать".

← →
Курдль © (2005-11-01 16:48) [93]

> Val © (01.11.05 16:31) [91]
> ...а в триггерах дублирование кода :) зачем вслепую отказываться
> от предлагаемых возможностей сервера? все равно ведь в теле
> триггера на диалекте писать будете :)

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

← →
TohaNik © (2005-11-01 16:59) [94]

> Курдль © (01.11.05 15:30) [89]

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

Например есть у нас ИНН на тыщ 20 контрагентов, ну не вижу я смысла проверять ни на каком уровне кроме как самой базой, тоже со счетами в комбинации с МФО.
Ну всеравно это "всем списком" не приведет ни к чему хорошему, тем более чем больше связей в сущности(многотабличном датасете) тем быстрее и не приведет.

← →
Val © (2005-11-01 16:59) [95]

почему же не поверю, всякое бывает :) мне все-равно сколько у вас там триггеров, только непонятно, к чему вы это...я оспариваю ваше высказывание о ненужности хп вообще-то :)

← →
TohaNik © (2005-11-01 17:06) [96]

> Не поверишь - сейчас рабочая база (с которой компания активно
> работает больше 2-х лет), в которой около 100 таблиц, многие
> из которых содержат более миллиона записей, не имеет ни
> одного триггера. Есть одна хранимая процедура - возвращает
> версию последнего апгрэйда базы.

Ну почему не поверим, охотно поверим, наверняка причины были.
Оч интересно какие?

← →
Курдль © (2005-11-01 17:09) [97]

> TohaNik © (01.11.05 16:59) [94]
> Ну всеравно это "всем списком" не приведет ни к чему хорошему,
> тем более чем больше связей в сущности(многотабличном датасете)
> тем быстрее и не приведет.

Разве не прЭлЭстно, когда датасэт копирует часть модели БД? Уверяю, что это весьма упрощает понимание БД, пограммирование доступа к БД и служит дополнительной защитой целостности данных.

> Val © (01.11.05 16:59) [95]
> непонятно, к чему вы это...я оспариваю ваше высказывание о ненужности хп вообще-то :)

А я не говорил о не нужности ХП в глобальном масштабе. Я говорил, что без них легко можно обойтись на уровне сервера приложений, если требуется проект, который может быть приспособлен к какой угодно СУБД на выбор заказчика. И это все вытекало из пользы трехзвенки, что напрямую связано темой топика! :)

← →
Val © (2005-11-01 17:12) [98]

>[97] Курдль © (01.11.05 17:09)
сорри тогда, не врулил. с этим согласен.

← →
TohaNik © (2005-11-01 17:32) [99]

> Разве не прЭлЭстно, когда датасэт копирует часть модели
> БД? Уверяю, что это весьма упрощает понимание БД, пограммирование
> доступа к БД и служит дополнительной защитой целостности
> данных.

Неужели без понимания БД стоит этот датасет создавать.
Что значит дополнительная защита целостности? Если она дополнительная в приложении к защите в базе то ее смысл наверняка в пояснительных диалогах и т.п., если нет то она не дополнительная, а основная т.к. база эту целостность не обеспечивает.

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

← →
Курдль © (2005-11-01 17:43) [100]

> Я не придираюсь, просто был свидетелем и потенциальным участником
> проекта с использованием этих самых многотабличных датасетов.

А я не могу понять, разве работа с сущностью, которая предполагает использование пяти таблиц, легче происходит с пятью разрозненными делфевыми датасэтами, чем с одним пятитабличным ADO.NET-овским?

> Неужели без понимания БД стоит этот датасет создавать.

Я в конкретный момент работаю над окном ввода и редактирования документа определенного типа. Передо мною, как всегда в таких случаях, напечатанная физическая субмодель БД, содержащая все таблицы касающиеся работы с документами, их связи, первичные и внешние ключи, поля, их типы и т.п. И как же удобно, когда на экране открыта схема датасэта, являющегося фрагментом этой субмодели!

← →
TohaNik © (2005-11-01 17:58) [101]

> И как же удобно, когда на экране открыта схема датасэта,

А никто и не спорит что видеть удобно, я про "всем списком" из [89], тем более для пяти таблиц. Для того же контрагета, в чем преимущество вставки скопом шапки и и списка банковских реквизитов?

> пятью разрозненными делфевыми датасэтами

Разрозненный он и один может быть, смотря что понимать по разрозненностью.

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

> Polevi © (02.11.05 10:03) [103]
> непонятно нафига тащить схему хранилища на клиента
> клиенту вообще по барабану в каком виде это все хранится

Ты не работал с VS.
Повторю свой пример - датасэт с таблицей юриков, их сотрудников и их банковских счетов.
"Бросаешь" такой датасэт на форму, бросаешь туда же DataGrid а лучше - dxControlGrid и получаешь таблицу с раскрывающимися нодами (типа аутлук), в которых на верхнем уровне иерархии юрики, а на следующем - все остальные.
Кроме того, я считаю бесценной возможность "гулять" по релэйшнам типа GetChildRows, GetParentRow. Есть и другие приятные возможности, которые на "однотабличном" датасэте реализовывать затибидохаешься.

> "Бросаешь" такой датасэт на форму, бросаешь туда же DataGrid
> а лучше - dxControlGrid и получаешь таблицу с раскрывающимися
> нодами (типа аутлук), в которых на верхнем уровне иерархии
> юрики, а на следующем - все остальные.

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

Ну все, мне уже тяжко спамить на эту тему :)
Я сам раньше очень любил программировать на ассемблере, но винды всю малину испортили. А теперь еще эта поганая .NET! :)

← →
freejack (2005-11-02 11:07) [108]

> Если не секрет какой проект имелся в виду? Что-то до боли
> знакомое...

Не думаю что знакомое...
Просто на одно из предприятий приехали бывшие советские граждане и решили показать как надо работать чтобы за год создать систему управления предприятием. А за год потому что VS и NET, а еще потому что они официальные представители MS. :)

← →
ali_tash (2005-11-02 19:54) [110]

они нужны чтоб откатать бабки за сервер приложений.

ГЫ ГЫ

Зачем нужны многозвенки ? Найти похожие ветки