Освобождение ресурса в finally

← →
Reindeer Moss Eater © (2008-05-07 11:19) [520]

Хотя все может свестись к терминальному режиму и той же двузвенке

← →
ANB (2008-05-07 11:41) [521]

> Хотя все может свестись к терминальному режиму и той же
> двузвенке

У нас терминал. Или как вариант - репликация между серверами филиалов (у нас нету).
Репликация будет даже лучше, чем аппсервер. Если филиал мелкий, то оракл мона развернуть на обычной рабочей станции.

← →
Palladin © (2008-05-07 11:44) [522]

Я трехзвенку начал создавать не от хорошей жизни и не из маркетинговых соображений. Дело в том что контора специализируется на конкретном виде приложений. Если абстрагироваться, то можно выделить основные выполняемые приложениями функции. Перенести эти функции на серевер, написать к ним API. В результате написание довольно простенького приложения занимает максимум неделю. При этом оно будет уже работать в распределенной инфраструктуре, поддерживать HTTPS и работу через HTTP-прокси. И ему будет по барабану на все каскады брендмауеров, бо работает оно по HTTP, админам ничем шевелить не нужно будет, что бы все заработало,ну разве что поднапрячься если будут использовать SSL, сертификаты раздать. Второй момент, API, API - построено уже в терминах сущностей предметной области любого приложения в этом виде. В некотором роде я написал очень легкий аналог JavaBeans и его сервера приложений, но со своей спецификой. Там же (на сервере) крутится механизм автообновления приложений. Сервер может работать с любой БД, к которой существует OLE DB провайдер, так что выбор сервера БД остается за заказчиком. Он может стартовать например с jet, при необходимости абсолютно безболезненной перейти на mssql или oracle (так горяче тобой любимый), бо обращения сервера к СУБД не уходят за рамки SQL-92. Специально так делалось. Теряем конечно производительность в некоторых случаях, но приобретаем гибкость и расширяемость. Хотя на всякий случай в API введена возможность подачи SQL запроса на БД. И представляешь, я сейчас делаю первые шаги в реализации даемона для freebsd, и представляешь, решит заказчик сменить платформу на сервере и кроме смены платформы ему ничего не придется делать... плюс у сервера приложений много других приятностей, сжатие данных, сохранение клиентских сессий (в случае необходимости рестарта), автоматическое обновление приложений (пакеты обновлений могут быть залиты обновлений) и ну и так по мелочи, для сопровожденцев...

Не бывать тебе архитектором, не дай бог... загубишь все... ты сначала хотя бы программистом стань... потому что так как описано в [503] пишут кодеры...

← →
Palladin © (2008-05-07 11:54) [523]

И вообще, задумывался ли ты, что используя браузер ты используешь как раз ту самую ненавистную тебе трехзвенную модель приложения?

← →
Palladin © (2008-05-07 12:03) [524]

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

← →
ANB (2008-05-07 12:06) [525]

> Palladin © (07.05.08 11:44) [522]

А чего вся эта байда полезного делает ?

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

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

> обращения сервера к СУБД не уходят за рамки SQL-92. Специально
> так делалось.
И кто это придумал ?
Бедные ваши заказчики.

> Не бывать тебе архитектором, не дай бог... загубишь все.
> .. ты сначала хотя бы программистом стань... потому что
> так как описано в [503] пишут кодеры...

Да бывал я уже архитектором. И внедренных проектов написанных как лично, так и командой хватает. Могу похвастаться - у меня нет НИ ОДНОГО заваленного проекта.
Тока сейчас архитекторам чет денег дают меньше, чем кодерам.

← →
ANB (2008-05-07 12:07) [526]

> лучше быть первоклассным кодером чем хреновым архитектором.
> .. да и ответственности меньше :)

А денег больше :)

← →
ANB (2008-05-07 12:09) [527]

> И вообще, задумывался ли ты, что используя браузер ты используешь
> как раз ту самую ненавистную тебе трехзвенную модель приложения?
>

Да хоть 15-ти звенную. Главное - с точки зрения прикладного программера - это однозвенка. Если все грамотно продумано.

← →
Palladin © (2008-05-07 12:12) [528]

> ANB (07.05.08 12:06) [525]

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

нафиг мне половина вашего объема? была бы половина вашего объема мне бы понадобилось другое решение :) нафиг мне размер твоей пиписки? :)

> И кто это придумал ?
> Бедные ваши заказчики.

Они очень даже счастливые :)

ты так ничего и не понял...

← →
Palladin © (2008-05-07 12:13) [529]

> ANB (07.05.08 12:09) [527]

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

← →
Игорь Шевченко © (2008-05-07 12:44) [530]

> хотя бы в половину нашего объема

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

← →
ANB (2008-05-07 14:32) [531]

> "половина нашего объема" - это неизвестная единица измерения.

Уточняю - наша база весит 20 террабайт. Относится к малым базам данных.
Половина - это 10 террабайт.

> Palladin © (07.05.08 12:13) [529]

А аппсервер никто не дорабатывает ?

> Они очень даже счастливые :)
>
> ты так ничего и не понял...

Это ты ничего пока не понял. С опытом поймешь.

По поводу универсализма (независимости от СУБД) :
решаем простенькую тестовую задачу.
Имеем 2 таблицы :
Т1
(
ИД
,Ф1
)

Т2
(
ИД
,Т1_ИД
,Ф2
)

Связь мастер-детал. Т.е., для примера - Т1 - список документов, Т2 - их строки.
Надо : в одной транзакции добавить документ и к нему пару строк.
И как ты извернешься с одинаковым запросом под мс скл и оракл ?

ЗЫ. Предметка так и не озвучена.

← →
Игорь Шевченко © (2008-05-07 14:43) [532]

ANB (07.05.08 14:32) [531]

> Уточняю - наша база весит 20 террабайт.

С картинками ?

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

Но мы отвлеклись от темы насчет трехзвенки и автоматизированной банковской системы.

Что должна уметь твоя система, сколько народу ей должно пользоваться, как и с какой интенсивностью ?

← →
ANB (2008-05-07 15:25) [533]

> С картинками ?

Не. Документы, проводки, аналитика по договорам и счетам.

Позволять заводить документы, проталкивать их по статусам, печатать чеки на ККМ, отправлять и принимать документы из/в РКЦ.
Проводить документы, отражая проводки и остатки на счетах.
Вести учет договоров кредитов и депозитов, начислять на них проценты.
Обмениваться данными с другими системами.

Народу - у нас немного, не больше 200 человек, т.к. АБС используется в качестве бэк-офиса.
Основные процессы идут на сервере.

← →
Игорь Шевченко © (2008-05-07 15:40) [534]

ANB (07.05.08 15:25) [533]

> Позволять заводить документы, проталкивать их по статусам,
> печатать чеки на ККМ, отправлять и принимать документы
> из/в РКЦ.
> Проводить документы, отражая проводки и остатки на счетах.
>
> Вести учет договоров кредитов и депозитов, начислять на
> них проценты.
> Обмениваться данными с другими системами.

Ну сам понимаешь, без трехзенки никуда :) Особенно в "проталкивании".

Мне слово "статус", "проводка", "ККМ", "РКЦ" и всякие кредиты с депозитами не говорят ничего.

Количество народу 200 человек тоже ничего не говорит, если они все сидят в одном тесном помещении, то достаточно локалки, если они равномерно распределены по планете, то локалки недостаточно - на кабеле разоришься да и сигнал затухнет, пока будет из Копена в Гаген идти.

← →
ANB (2008-05-07 15:50) [535]

> Ну сам понимаешь, без трехзенки никуда :)

Дык как то без нее обходимся. Нам тока аппсерверов для полного счастья не хватает.

ЗЫ. Куда то палладин пропал. Так и не решил задачку. Наверное, задумался об архитектуре своего монстра.

← →
ANB (2008-05-07 15:52) [536]

> Мне слово "статус", "проводка", "ККМ", "РКЦ" и всякие кредиты
> с депозитами не говорят ничего.

Статус - состояние документа (тока введен, проверен, проведен)
Проводка - тоже самое как в бухгалтерии. Дебет кредит
ККМ - хреновина, которая печатает кассовые чеки под управлением компутера
РКЦ - расчетно-кассовый центр. через них проходят наши переводы из одного банка в другой. Обмен файловый.

← →
Palladin © (2008-05-07 15:59) [537]

> Надо : в одной транзакции добавить документ и к нему пару
> строк.

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

> ЗЫ. Предметка так и не озвучена.

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

сам назови эту область как хочешь...

> Это ты ничего пока не понял. С опытом поймешь.

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

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

← →
Игорь Шевченко © (2008-05-07 16:17) [538]

ANB (07.05.08 15:52) [536]

Это все конечно хорошо, только сильно напоминает одну задачку - есть на входе текстовый файл, оформленный по неким правилам, надо его прочитать и сформировать на выходе двоичный файл, тоже по неким правилам.

← →
ANB (2008-05-07 16:24) [539]

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

Большой и толстый документооборот. Напоминает АБС.
И ты хочешь сказать, что количество записей в таблицах расти не будет ?
А по задачке - я разве просил это выполнить обязательно с клиента ?
Приведи пример скрипта, который будет одинаков и для оракла и для мс скл.

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

Задумывался. Выяснил, что архитекторам сейчас таки меньше платят. Застой на рынке ИТ.

← →
ANB (2008-05-07 16:26) [540]

> Игорь Шевченко © (07.05.08 16:17) [538]

Хорошо. Возьми сам любую знакомую предметку, которая требует для работы базу данных.

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

← →
Игорь Шевченко © (2008-05-07 16:39) [541]

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

Доступ с разных концов страны

← →
ANB (2008-05-07 16:51) [542]

> Игорь Шевченко © (07.05.08 16:39) [541]
>
> > И озвучь, чего я не смогу сделать на оракле, чтобы понадобился
>
> > аппсервер.
>
>
> Доступ с разных концов страны

Уточняем условия :
имеем 40 офисов по России и 20 за бугром. В кажном офисе от 100 до 5 человек. В головном сидит почти 1000.
Все сидят за компами и стучат клавишами - оформляют документы и пишут письма.
Задача : надо что бы все документы проходили через единую БД, но при этом работало все надежно, не тормозило и не падало, если какой то экскаваторщик в урюпинске расхреначил федеральный кабель москва-владик, у спутника связи сдохла батарея, и ближайший резервный канал связи откроется тока через 4 часа. И при этом будет безбожно тормозить.

Так пойдет ?

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

← →
Palladin © (2008-05-07 16:58) [543]

> ANB (07.05.08 16:24) [539]
> И ты хочешь сказать, что количество записей в таблицах расти
> не будет ?

конечно оно растет, БД коммунальных платежей за 4 года аж 9гб... НПА (норм.прав.акты) за 3 года аж до 2гб, за счет того что заказчик решил хранить приложения и документы офиса в базе... это самые крупные базы...

> А по задачке - я разве просил это выполнить обязательно
> с клиента ?
> Приведи пример скрипта, который будет одинаков и для оракла
> и для мс скл.

он не будет одинаков, как я уже сказал

> если понадобится та или иная специфика работы с БД,

← →
ANB (2008-05-07 17:08) [544]

> если понадобится та или иная специфика работы с БД,

Во. Т.е. об универсальности речь уже не идет.
Диасофт со своей поддержкой 2-х СУБД уже вешается.

> конечно оно растет, БД коммунальных платежей за 4 года аж
> 9гб... НПА (норм.прав.акты) за 3 года аж до 2гб, за счет
> того что заказчик решил хранить приложения и документы офиса
> в базе... это самые крупные базы...

Во. А говорил, что объемов нету.
И по мере развития системы они будут расти еще быстрее.
Дальше система начнет обрастать все большим и большим количеством отчетов, которые начнут тормозить на стандартном скл.
Потом вылезут ночные техпроцессы. Когда время их выполнения превысит 12 часов, единственным правильным решением будет начать переносить их на серверную логику.
И лучше этот момент продумать сразу, пока не начали стучать по голове заказчики.

← →
Palladin © (2008-05-07 17:10) [545]

> ANB (07.05.08 17:08) [544]

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

← →
Palladin © (2008-05-07 17:12) [546]

> Дальше система начнет обрастать все большим и большим количеством
> отчетов,

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

> Во. Т.е. об универсальности речь уже не идет.

речь шла о том, что смена БД никак не повлияет на работу приложений-клиентов... а на серверную сторону повлияет лишь тем, что если есть какая то специфика, то конечно ее придется подправить...

← →
Palladin © (2008-05-07 17:14) [547]

> Диасофт

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

← →
Reindeer Moss Eater © (2008-05-07 17:24) [548]

двузвенка никогда не может быть отрешена от БД,

да лехко. или по крайней мере иногда. но никогда - "никогда".

ANB (07.05.08 16:51) [542]

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

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

Я конечно сильно извиняюсь, но как тебе поможет репликация при требовании "что бы все документы проходили через единую БД" ?

Ты собираешься свои 20 терабайт на каждой локальной точке держать ?

> Reindeer Moss Eater © (07.05.08 17:24) [548]

вообще говоря в частном случае решается конечно

и в общем тоже, но при помощи создания встроенного в приложение среднего звена :)

← →
ANB (2008-05-07 17:29) [551]

> двузвенка никогда не может быть отрешена от БД

У диасофта как раз трехзвенка. А мона сдуру и двухзвенку написать отвязанную от конкретной БД. Достаточно использовать АДО. Но я такой дурью никогда маятся не буду.

> а на серверную сторону повлияет лишь тем, что если есть
> какая то специфика, то конечно ее придется подправить...
>

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

> одна из задачь трехзвенки - как раз абстракция клиентского
> проложения от какой либо БД

Трехзвенка для этих целей ничем не круче двухзвенки.

> а каким образом объем БД влияет на производительность многозвенки?

Начнут тормозить запросы к БД.
Особенно, когда запустишь отчет "По всем документам за год".

Из опыта : очень плохо, когда текст скл живет в приложении. Скл надо держать на хранимках. Иначе будет много граблей при сопровождении и модификации.

← →
ANB (2008-05-07 17:31) [552]

> Ты собираешься свои 20 терабайт на каждой локальной точке
> держать ?

Зачем ? На кажной точке - тока нужные ей документы.

А уж если нужно кажный раз лазить в центральную БД, то с этим терминальный доступ справится.

> Из опыта : очень плохо, когда текст скл живет в приложении.
> Скл надо держать на хранимках. Иначе будет много граблей
> при сопровождении и модификации.

А какая разница ?

> Начнут тормозить запросы к БД.
> Особенно, когда запустишь отчет "По всем документам за год".

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

> У диасофта как раз трехзвенка

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

> Ты попробуй, реши мою тестовую задачку.

какую? про xml чтоли? условия плиз исполнения, где файл лежит, кто чего получает..

> очень плохо, когда текст скл живет в приложении

а вот тут батенька, я тебя жестоко обламаю, в приложении клиентском нет ни одного SQL скрипта

← →
ANB (2008-05-07 17:33) [555]

> и в общем тоже, но при помощи создания встроенного в приложение
> среднего звена :)

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

ANB (07.05.08 17:31) [552]

> Зачем ? На кажной точке - тока нужные ей документы.

Тогда это несовместимо с требованием "что бы все документы проходили через единую БД" или ты под требованием понимаешь одно, а озвучиваешь другое.

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

Во-первых, терминальный доступ - это та самая многозвенка о который ты говоришь (тонким клиентом выступает Terminal Services Client), во-вторых, я не совсем понимаю, каким образом поможет терминальный доступ при локальных базах, в-третьих, я не до конца понял с репликацией - что куда реплицируется через поиск резервных каналов связи и т.п. ?

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

чего чего простите делать с текстом запроса?

← →
ANB (2008-05-07 17:42) [558]

> А какая разница ?

В хранимках сразу видны ошибки в тексте запроса. На этапе компиляции. А при хранении запроса в приложении ошибки выявятся тока на тестировании при входе в эту ветку.

> запрос он и есть запрос, и его производительность от СУБД
> зависит, а не от многозвенности приложения...

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

> > Ты попробуй, реши мою тестовую задачку.
>
> какую? про xml чтоли? условия плиз исполнения, где файл
> лежит, кто чего получает..

Про добавление записей в две таблички при их мастер-детал связи.

> а вот тут батенька, я тебя жестоко обламаю, в приложении
> клиентском нет ни одного SQL скрипта

А аппсервер твой - это не приложение ? Где я писал, что в клиентском ?

> ANB (07.05.08 17:42) [558]

1. ты тему разности производительности в случае многозвенности и двузвенности не открыл
2. ты перешел на тему отчетности, отченость реализованна полностью на серверных скриптах (это не SQL скрипты, это Pascal Script"ы), это твоя любимая двухзвенность, клиенту аппсервера передается лишь данные о создании отчета и в итоге сам созданных файл
3. при работе не с отчетом, а с сущностью, я уже сказал либо используется подход встроенной совместимости с SQL-92, либо если лучше все таки отработать со спецификой БД, то пишется скрипт с синтаксисом Pascal"я, который призван отработать звеном между БД и приложением клиента...

вопросы

← →
ANB (2008-05-07 17:51) [560]

> Во-первых, терминальный доступ - это та самая многозвенка
> о который ты говоришь (тонким клиентом выступает Terminal
> Services Client), во-вторых, я не совсем понимаю, каким
> образом поможет терминальный доступ при локальных базах,
> в-третьих, я не до конца понял с репликацией - что куда
> реплицируется через поиск резервных каналов связи и т.п.
> ?

1. Терминал и репликация - 2 разных решения.
С терминалом - уел. Пусть будет нужна трехслойка. Хотя аппсервер здесь тоже может быть тонким и бизнес логику в него пихать смысла нету.
С другой стороны, при отсутствии связи вообще, удаленный офис не сможет работать совсем.
Репликация - процесс обмена данными между отдельными серверами. Филиалы все свои документы отправляют в центральный офис. Сами получают тока нужные им документы.
Поиск резервных каналов связи : пишется специальное приложение, которое занимается только транспортом данных от сервера к серверу.
Оно должно уметь находить запасные рабочие каналы связи при отказе основных. Есно, эти запасные каналы связи сначала надо организовать, а в приложение засунуть из параметры и научить его работать с ними.
Такая штука была реализована в "МВ офисная техника" и работала довольно продуктивно.
При использовании репликации офисы смогут ограниченно работать даже при полном отсутствии связи с центром.

Освобождение ресурса в finally Найти похожие ветки