Delphi 2005

← →
vuk © (2004-12-06 19:33) [120]

to Суслик © (06.12.04 19:29) [119]:
>Кто отслеживает? Кто совершает?
Пусть в документе 10 позиций. Пока мы редактировали их на клиенте, все было нормально, но когда решили сохранить изменения,
3 из них не прошли проверку по каким-то условиям. Что делать?

← →
DiamondShark © (2004-12-06 19:33) [121]

> При сохранении факт изменения справочника отловится. И в
> зависимости от контекста будут выполнены те или иные действия.

И в чём тогда смысл навороченной валидации на клиенте? Если на сервер всё равно могут быть отправлены невалидные данные (причём в большом объёме).

Я ж говорю: надо двадцать раз думать, прежде чем применять метафору документа.

← →
wisekaa © (2004-12-06 19:38) [122]

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

Составляющая изменена, а пересчет пойдет со старыми данными?
Затреться ли правка составляющей документа, при сохранении всего документа?

← →
wisekaa © (2004-12-06 19:39) [123]

Пока набирал, мой вопрос прозвучал, правда в другом контексте.

← →
DiamondShark © (2004-12-06 19:44) [124]

> wisekaa © (06.12.04 19:38) [122]

Это решается на уровне прикладных правил, а не серверными средствами.

← →
Суслик © (2004-12-06 19:47) [125]

> [120] vuk © (06.12.04 19:33)
> Пусть в документе 10 позиций. Пока мы редактировали их на
> клиенте, все было нормально, но когда решили сохранить изменения,
> 3 из них не прошли проверку по каким-то условиям. Что делать?

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

> [121] DiamondShark © (06.12.04 19:33)

> И в чём тогда смысл навороченной валидации на клиенте? Если
> на сервер всё равно могут быть отправлены невалидные данные
> (причём в большом объёме).

В том, что:
1. При сохранении класс опрашивается, какие классы в БД нужно exclusive заблокировать. По умолчанию - это родитель.
2. Проверки на клиенте происходят в контектсе exclusive доступа к нужным дынным (повторю, что класс определяет данные, которые нужно заблокировать).
3. На сервере есть перепроверки некоторых условий состоятельности данных. Но не всех. Т.к. иначе в него пришлось бы тащить логику.

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

> [122] wisekaa © (06.12.04 19:38)

> А как быть с наложением ввода?

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

← →
wisekaa © (2004-12-06 19:50) [126]

>> [124] DiamondShark © (06.12.04 19:44)
А я и не говорю о серверной реализации.

<OffTopic>
Суслик, фотки когда ожидать?
</OffTopic>

← →
vuk © (2004-12-06 19:50) [127]

to DiamondShark © (06.12.04 19:44) [124]:
>Это решается на уровне прикладных правил, а не серверными
>средствами.
Ну... Можно и серверными. В MSSQL блокировка "документов" замечательно делается при помощи блокировок уровня приложения.

← →
Суслик © (2004-12-06 19:51) [128]

<alsoOffTopic>
когда фотик на работу принесу.
Постараюсь завтра.
</alsoOffTopic>

← →
vuk © (2004-12-06 19:58) [129]

to Суслик © (06.12.04 19:47) [125]:
>В этом случае можно сделать именно так - отворот, поворот -
>вводи заново (вернее, оредактируй ввод).
При этом, скорее всего, получится узнать только о первой ошибке, а не об остальных двух оставшихся. Веселуха будет, если после правки строки номер 2 перестанет проходить проверку строка номер 5, которая раньше ее проходила... И так - до тех пор, пока все условия не выполнятся?

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

← →
DiamondShark © (2004-12-06 20:01) [130]

> vuk © (06.12.04 19:50) [127]
> Ну... Можно и серверными. В MSSQL блокировка "документов"
> замечательно делается при помощи блокировок уровня приложения.

Што?! На всё время редактирования?

← →
DiamondShark © (2004-12-06 20:03) [131]

Мда... Дельфи 2005 нежно похерили ;)
Клиент-сервер архитектура намного интереснее.
;-)

← →
Суслик © (2004-12-06 20:05) [132]

> [129] vuk © (06.12.04 19:58)

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

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

← →
vuk © (2004-12-06 20:05) [133]

to DiamondShark © (06.12.04 20:01) [130]:
>Што?! На всё время редактирования?
А што? :o) Открыл "документ" - вызвал sp_getapplock, вышел - sp_releaseapplock. Проверять можно хоть на клиенте хоть на сервере. В случае, если клиент отвалился, блокировка уходит.

← →
}|{yk © (2004-12-06 20:05) [134]

Почему иногда лучше написать промежуточный сервер? А как вы на sql реализуете формулы (причем некоторые могут занимать несколько страниц - в финучёте это не редкость)

← →
Суслик © (2004-12-06 20:10) [135]

> [131] DiamondShark © (06.12.04 20:03)
> Мда... Дельфи 2005 нежно похерили ;)
> Клиент-сервер архитектура намного интереснее.
> ;-)

Я тоже заметил.
Сам-то - просил не флеймить, а развел тут :)))

Клиент-сервер - это вечно! А дельфи (мн. число) приходят и уходят )

← →
iZEN © (2004-12-06 23:46) [136]

А как насчёт вебсервисов?
Что, заглохло совсем?

← →
Petr V. Abramov © (2004-12-07 02:18) [137]

> Суслик © (06.12.04 20:10)
> ... документа, который обладает 1-3 уровневыми master-detail с
> нефиговой логикой зависимостей полей. Грубо говоря - тут
> поравил, пересчитался весь документ (полей так 200).
Прям квадратный двухсотчлен какой-то :) И пользователь все эти 200 полей смотрит??? И они на экран помещаются?

← →
KSergey © (2004-12-07 08:14) [138]

> [59] Суслик © (06.12.04 15:43)
> Ты слышал, что С. Орлик говорил недели две назад (можешь
> поиском поискать)?
>
> "Life time delphi 6 кончился."

А можно цитатку точнее или может не сочтете за труд ссылочку дать, а? А то что-то не выходит у меня найти...

PS
Зато с удивлением обнаружил такую вот ветку на данном форуме от 2003 года, поразительно, но не ушедшую в архив:

http://delphimaster.net/view/10-1070985161/

← →
Sergey_Masloff (2004-12-07 09:13) [139]

}|{yk © (06.12.04 20:05) [134]
>А как вы на sql реализуете формулы (причем некоторые могут >занимать несколько страниц - в финучёте это не редкость)
Ой да ладно. В страховании расчет текущих резервов и покруче формулы дает. И ничего - пишется как-то.
Как уже сказано - если есть методика то написать ее можно на чем угодно (а на внутреннем языке SQL сервера даже легче потому что доступ к данным быстрее и прозрачнее). Если методики нет то написать нельзя ни на чем.

← →
Суслик © (2004-12-07 10:12) [140]

> [138] KSergey © (07.12.04 08:14)

Она вроде в архив уже ушла - месяц назад была

> [137] Petr V. Abramov © (07.12.04 02:18)

Зачем влезать? Форма интерактивная. Все сразу не видно.

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

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

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

Прикажешь каждый раз это делать на сервере? Он же загнется.

Все легко и просто.

← →
Суслик © (2004-12-07 10:28) [141]

> [143] Sergey_Masloff (07.12.04 09:13)
>Если методики нет то написать нельзя ни на чем.

Не слова, а золото :))

← →
Andryk © (2004-12-07 10:34) [142]

Гм как вы, однако, отошли от темы, и переключились на различия в архитектуре. Ну, тогда выскажусь и я по этому поводу. Я тоже долгое время был противником использования СУБД просто как хранилища данных. Но в последнее время я пересмотрел свою позицию. Несколько причин, по которым все же следует строить системы по трехзвенной архитектуре (в основном это применимо к J2EE):
1. Независимость от СУБД. При наличии драйверов к БД вас не заботит диалект SQL, на котором "говорит" БД. Это дает возможность легко поменять БД для конкретного заказчика, если есть у него деньги, то Oracle, нет денег или желания тратить деньги на дорогую СУБД, то можно на бесплатных версиях IB.
2. Бизнес слой пишется на одном языке, который не зависит от СУБД. Это опять же дает простой переход к любой БД, так, например, если бы кто-нибудь попробовал бы перенести клиент-серверную систему с Oracle на MsSql, да еще и поддержка у двух разных заказчиков. Думаю что это была бы не тривиальная задача, т.к. когда я работал в одной конторе, там было несколько заказчиков, а у одного стоял Oracle 7 версии у других Oracle 8 и у же были большие проблемы поддерживать системы.
Эти два пункта сильно удешевляют систему и, следовательно, привлекают больше клиентов.

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

Теперь по поводу ECO, ИМХО, это просто технология построения толстого клиента для клиент-серверной архитектуры, с возможностью легкого перехода на трехзвенную структуру, основанной, например на J2EE.

← →
Sergey_Masloff (2004-12-07 11:09) [143]

Andryk © (07.12.04 10:34) [142]
>1. Независимость от СУБД.
Это сказки. Объясню почему - если система может работать с разными СУБД то она работает с ними как с наименее функциональной из всего набора. Тот "учет специфики сервера" который декларируется некоторыми ORM это детский лепет.
Просто получается вы обкрадываете своих клиентов которые используют более мощные серверы СУБД так как их (немалые) деньги уплаченые за мощь сервера выбрасываются на ветер. Потому что в качестве простой свалки таблиц ORACLE ничуть не лучше (если не хуже) того же интербейса или mysql (последний даже точно лучше так как из-за примитивности транзакционной работы быстрее функционирует). Ведь так? ;-)
Но это я со своей колокольни. Тем более если у кого-то нашлись деньги на нашу систему то покупка Оракла, лицензий и железа будет для него мелочью ;-)))

← →
Суслик © (2004-12-07 11:17) [144]

> [143] Sergey_Masloff (07.12.04 11:09)

Почему не верите в независимость от субд?
В полном объеме и я в нее не верю. Но ведь это уровень провайдера (своего). Напиши штук 10 провайдеров по переводу своих метаданных в конкретный код конкретного сервера.

Мы пока живет только для ms sql. Но это дело одног-двух месяцев вынести все в отдельный класс, который полимоврфно бы использовался. Еще дело нескольких месяцев и несколькоих спецов конкретного сервера написать билдер запросов для oracle или еще для чего.

Конечно, руками писать оптимальнее. Я не спорю. Но определенную долю оптимизации можно и тут делать. Например в нашем построителе для join есть управление оптимизатором в виде merge или hash в зависимости от контекста использования.

← →
DiamondShark © (2004-12-07 11:20) [145]

> Тот "учет специфики сервера" который декларируется некоторыми
> ORM это детский лепет.

Нет, ну почему же...
С учётом специфики сервера можно сделать довольно эффективную надстройку. Вот только "независимость" сразу куда-то девается ;-)

← →
Суслик © (2004-12-07 11:32) [146]

> Нет, ну почему же...
> С учётом специфики сервера можно сделать довольно эффективную
> надстройку. Вот только "независимость" сразу куда-то девается
> ;-)

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

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

← →
Andryk © (2004-12-07 11:32) [147]

> Sergey_Masloff (07.12.04 11:09) [143]
> Andryk © (07.12.04 10:34) [142]
> >1. Независимость от СУБД.
> Это сказки. Объясню почему - если система может работать
> с разными СУБД то она работает с ними как с наименее функциональной
> из всего набора. Тот "учет специфики сервера" который декларируется
> некоторыми ORM это детский лепет.

Как вы думаете выборка значения по ключам это эфекитвный способ? Так вот J2EE обращается к к БД по ключам, старается конечно по первичным. Да конечно она не строит многоуровневые запросы, но это ей и не надо. Там также есть возможность написания своих собственных запросов, для обращения и изменения данных, но как только вы привязываетесь к конретной СУБД. Вы сразу сужаете круг потенциальных клиентов. А мощь СУБД можно использовать для построения отчетов.

← →
Суслик © (2004-12-07 11:33) [148]

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

во и я тоже самое говорю.

Не фиг мешать отчеты и insert\update\delete. Разные вещи, имхо.

>Sergey_Masloff (07.12.04 11:09) [143]
>Это сказки.

А как же SAP?

← →
Sergey_Masloff (2004-12-07 11:45) [150]

euru © (07.12.04 11:36) [149]
>А как же SAP?
А никак. См. что я писал выше. В SAP РОВНО то же самое.

Суслик © (07.12.04 11:33) [148]
>Не фиг мешать отчеты и insert\update\delete.
Ага. Только есть системы в котором без отчета никакого update не бывает ;-)

Независимость от СУБД это не сказки. Comshare MPC может использовать Oracle, MS SQL, ESBase и еще некоторые СУБД. И работает с вполне нормальной скоростью.

> [150] Sergey_Masloff (07.12.04 11:45)
> euru © (07.12.04 11:36) [149]

> Только есть системы в котором без отчета никакого update не бывает ;-)

А мое какое дело? У меня такая система? Вроде нет... Спасение утопающих, ну ты знаешь... :))

>Sergey_Masloff (07.12.04 11:45) [150]

А вы уверены, что если к свалке таблиц добавить свалку хранимых процедур, то производительность системы клиент/сервер увеличится?

← →
Sergey_Masloff (2004-12-07 12:11) [155]

euru © (07.12.04 12:01) [154]
>А вы уверены, что если к свалке таблиц добавить свалку хранимых >процедур, то производительность системы клиент/сервер >увеличится?
На 100%. Потому что доступ к обрабатываемым данным обеспечивается максимально эффективным способом. А ведь обработка данных - основная задача? Или и по этому вопросу возражения имеются? ;-)

}|{yk © (07.12.04 11:46) [151]
>может использовать Oracle, MS SQL, ESBase и еще некоторые СУБД. >И работает с вполне нормальной скоростью.
Я считаю нормальной только максимально возможную скорость. Ну вот такое мое ИМХО.
Кстати и активно пиарящаяся вами Comshare MPC правильность универсального подхода не особо доказывает. Да, есть такая система но во-первых бюджетирование не особо сложная для отображения в объектную модель область во-вторых там не особой многопользовательскости ни больших объемов данных и не требуется. Так что пример неудачный. Следующий ;-)

Следующий ;-)

Я!

Что париться из-за недопоставленной задачи: разные задачи, разные решения.

Где-то это важно

> Я считаю нормальной только максимально возможную скорость.
> Ну вот такое мое ИМХО.

где-то большую важность имеет гибкость и пр.

Зачем спорить...

> Sergey_Masloff (07.12.04 12:11) [155]
euru © (07.12.04 12:01) [154]
>>А вы уверены, что если к свалке таблиц добавить свалку
>> хранимых >процедур, то производительность системы
>> клиент/сервер >увеличится?

> На 100%.
пессимист :)

Как это ни особой многопозовательности? Питерская фирма КОРУС установила данную систему в (забыл как точно называется) российский аналог "Укртелекома". Данные поступают постоянно со всей России на центральный сервер. И объемы данных большие.

← →
Sergey_Masloff (2004-12-07 12:22) [159]

Суслик © (07.12.04 12:15) [156]
>Зачем спорить...
Экшн. Это раз. Ну и во вторых - раз есть спор значит есть мнения. Думаешь стал бы я спорить с тобой (сюда можно подставить и других) если бы твое мнение меня не интересовало?
Ну написал бы "да, правильно" и дело с концом. Ветка на 3 сообщения была б. А так вот как разрослось. Правда куда нам до украины но хоть что-то.

← →
Sergey_Masloff (2004-12-07 12:24) [160]

}|{yk © (07.12.04 12:19) [158]
>И объемы данных большие.
Ну откуда в бюджетировании большие данные? Не знаю. Ну ладно поверю пока на слово ;-)

Delphi 2005 Найти похожие ветки