Уходя от DBAware, зашился. Что можно мне посоветовать?

← →
12 © (2010-12-28 10:01) [0]

Хотелось, чтоб не напрямую редактировал пользователь. Стал делать простые TEdit, TStringGrid и т.п.
Перед загрузкой все заполняется, по кнопке все пробегается, перезапрашивается БД, и смотрится что менялось, потом только выборочно это и апдейтится.

4й или 5й раз меняется ТЗ, опять все менять, форм много, контрлов тоже. Чувствую, могу не успеть все это "ручное" переписать "в ручную"..
Но и не хочется DBAware делать.

TClientDataSet рассматриваю, но что-то не нравится, на первый взгляд. Наверное, потому что не юзал еще никогда :)

Юзать или не юзать? или что-то еще можно придумать?

← →
Ega23 © (2010-12-28 10:19) [1]

НД - только на чтение. Из DBAware - только DBGrid + были у меня несколько вспомогательных контролов и компонентов типа DBImageList.
CDS - я честно говоря не очень представляю архитектуру, где он жизненно необходим.

← →
Petr V. Abramov © (2010-12-28 10:30) [2]

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

перезапрос убивает всю экономию от "выборочно это и апдейтится."
обычный датасет + CachedUpdates.

← →
Sergey13 © (2010-12-28 10:35) [3]

Какая то БД-фобия, ИМХО.

← →
Ega23 © (2010-12-28 10:49) [4]

> обычный датасет + CachedUpdates.

Для одного клиента - отличное решение. Для 100 - ..опа, ибо данные безнадёжно устаревают.

← →
12 © (2010-12-28 10:55) [5]

клиентов около 30. максимум.

← →
Petr V. Abramov © (2010-12-28 11:06) [6]

> Ega23 © (28.12.10 10:49) [4]

> Для одного клиента - отличное решение. Для 100 - ..опа,
> ибо данные безнадёжно устаревают.

умничко :)
осталось найти технологию,
- при которой устаревают небезнадежно
- идеологически несовместима с обычный датасет + CachedUpdates.
переоткрывать раз 0.1 сек, mssql, xml и пр. г... не предлагать

← →
Ega23 © (2010-12-28 11:09) [7]

> клиентов около 30. максимум.

Ну я бы именно так бы и поступил.
Типичная картина: форма, DBGrid, в ней - ну например какой-то справочник. НД - только для чтения. Хочешь подредактировать - дабл-клик на записи, вывалилась модальная форма. В модальную форму передался ID записи, выполнился запрос на вытаскивание актуальных на данный момент данных. Заполнились всякие Edit-ы, комбо-боксы, чек-боксы и т.д.
Пользователь отредактировал как надо, нажал "Применить". Прошла проверка на валидность (ну это уже по бизнес-логике), данные обновились в базе, форма закрылась, НД в изначальной форме обновился (в любом случае, даже если "Отмена" нажали), НД спозиционировался на запись с данным ID.

← →
12 © (2010-12-28 11:10) [8]

> обычный датасет + CachedUpdates.

м-да. Как обычно, слона и не заметил.
Ща одну форму переделал минут за 10 - нормально, вроде..

Спасибо!

← →
DiamondShark © (2010-12-28 11:11) [9]

> Ega23 © (28.12.10 10:49) [4]
> Для 100 - ..опа, ибо данные безнадёжно устаревают.

При connected-модели доступа для 100 клиентов "опа" настанет раньше.

Вообще-то, disconnected-модель доступа была придумана для того, чтобы минимизировать нагрузку на СУБД и уменьшить взаимовлияние клиентов.

ЯХДР. 2011 год скоро. А дельфисты всё ещё эмулируют методы доступа ФоксПро.

← →
XXL (2010-12-28 11:12) [10]

Я к такому выводу (отказаться от DBAware компонент) пришел примерно на 5-й год разработки под DB.
Для вывода используются TMS Unicode. Запросы на обновление формируются вручную по шаблону.

← →
DiamondShark © (2010-12-28 11:12) [11]

> Юзать или не юзать? или что-то еще можно придумать?

Что тут придумывать? Выкинуть мусор на помойку, взять VS.NET и радоваться жизни.

← →
12 © (2010-12-28 11:14) [12]

> Ega23 © (28.12.10 11:09) [7]

ну так и делал примерно. Но это ужас же..

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

← →
12 © (2010-12-28 11:15) [13]

> Что тут придумывать? Выкинуть мусор на помойку, взять VS.
> NET и радоваться жизни.

не, отклоняется, однозначно.

← →
DiamondShark © (2010-12-28 11:15) [14]

> Ega23 © (28.12.10 11:09) [7]

Потом это приложение отдали на поддержку другому программисту, и в стране ухудшилась криминогенная ситуация.

← →
DiamondShark © (2010-12-28 11:16) [15]

> 12 © (28.12.10 11:15) [13]
> не, отклоняется, однозначно.

*пожимает плечами*

← →
12 © (2010-12-28 11:17) [16]

когда все устоится (пару месяцев будет работать без правок) обязательно все же перепишу как было. Edit, Grid и т.п.
Все же так правильнее, имхо.

← →
Ega23 © (2010-12-28 11:21) [17]

> При connected-модели доступа для 100 клиентов "опа" настанет
> раньше.

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

> 12 © (28.12.10 11:10) [8]
> Ща одну форму переделал минут за 10 - нормально, вроде..

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

З.Ы. Естественно, всё зависит от задачи и от требований к системе. Я 8 лет СКУД-ами занимался, там это было (по тем ТЗ) вполне обоснованно, и даже необходимо.

← →
DiamondShark © (2010-12-28 11:23) [18]

Идея DBAware компонент была в своё время если и не хороша, то, по крайней мере, оправдана тем, что любые имеющиеся тогда альтернативы были ещё хуже.
Теперь этот подход явно морально устарел.

← →
Ega23 © (2010-12-28 11:28) [19]

> DiamondShark © (28.12.10 11:23) [18]
>
> Теперь этот подход явно морально устарел.

За язык тебя никто не тянул, так что давай, объясняй почему.

← →
DiamondShark © (2010-12-28 11:28) [20]

> Ega23 © (28.12.10 11:21) [17]
> А кто тебе сказал, что приложение напрямую с СУБД работает?

Да пофиг.

> Я про общую концепцию говорю

Какую, нахрен, концепцию? Какая, к лешему, концепция избавит от устаревания данных во время редактирования? Чо ты мОзги пудришь?

← →
12 © (2010-12-28 11:32) [21]

> Какая, к лешему, концепция избавит от устаревания данных
> во время редактирования?

как будто в VS.NET избавит как то

← →
Ega23 © (2010-12-28 11:37) [22]

> Какая, к лешему, концепция избавит от устаревания данных
> во время редактирования? Чо ты мОзги пудришь?

Не во время редактирования.
Я открыл форму с набором данных. И ушёл сначала на перекур, потом на обед, а потом ещё куда-то. Меня не было, например, час. За это время данные были модифицированы другими пользователями. Не все, но какая-то часть. Например, 10%.
Я вернулся и дабл-кликнул на какую-то запись. У меня в модальную форму передался ID данной записи. Из формы пошёл запрос на актуальные данные по этому ID. Они отобразились, я их отредактировал, либо вообще отмену нажал. И вот уже потом пошёл рефреш основного набора. Того, который был на 10% изменён.

← →
Petr V. Abramov © (2010-12-28 11:43) [23]

> 12 © (28.12.10 11:32) [21]
>
>
> > Какая, к лешему, концепция избавит от устаревания данных
> > во время редактирования?
>
> как будто в VS.NET избавит как то

здохнешь и отмучаешься :)

← →
vuk © (2010-12-28 11:50) [24]

to Ega23 © (28.12.10 11:37) [22]:

> Они отобразились, я их отредактировал, либо вообще отмену
> нажал.

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

Собсно, у нас по такому принципу всё и живет. В обычной двухзвенке. И с обычными DB-aware. Проблем нет.

← →
Ega23 © (2010-12-28 11:53) [25]

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

А, ну да, это тоже. Забыл написать. Типа "Эта запись редактируется Васей Пупкиным с рабочей станции Workstation".

← →
DiamondShark © (2010-12-28 12:50) [26]

> Ega23 © (28.12.10 11:28) [19]
> > DiamondShark © (28.12.10 11:23) [18]> > Теперь этот
> подход явно морально устарел.За язык тебя никто не тянул,
> так что давай, объясняй почему.

Потому что появилась явно более обобщённая и удобная модель data binding, в которой нет разницы между ДБ и не-ДБ контролами, а источником данных может быть не только датасет, но и любой объект вообще.

В дельфи ДБ-контролы были сделаны на скорую руку, потому что ни у кого такой фичи не было, а на рынок выходить надо было. Во времена Д-1 это была действительно суперская фича, а теперь уши аврального решения торчат слишком явно.
В ДБ-контролах нет никакой общей абстракции и единообразия.
Так, например, ДБ-контролы не имеют общего корня наследования. Т.е., нет иерархии вида:
TControl - TDBControl
- TDBEdit
- TDBDateTimePicker
и т.д.
Ну ладно, вывод из единого корня -- не единственный вариант построения семейств объектов. Есть, к примеру, ещё подходы агрегации, примесей, аспектов и т.п.
Но дельфийские ДБ-контролы не тянут ни на агрегаты, ни на носители аспектов и примесей. С ними вообще нельзя обращаться каким-либо абстрагированным и унифицированным способом.
Их БД-шность реализована тупым копипастом!

← →
DiamondShark © (2010-12-28 12:51) [27]

> А пока ты их редактируешь, на них должна быть блокировка
> поставлена,

Привет^Wпрощай масштабируемость.

← →
DiamondShark © (2010-12-28 12:55) [28]

> Ega23 © (28.12.10 11:37) [22]

Не-не-не, Дэвид Блэйн. Я предлагаю другой сценарий.

Я кликнул запись, у меня открылась модальная форма со свежей записью, я изменил половинну полей, и только потом пошёл курить/обедать/какать/пиво пить.

А потом вернулся и нажал "Сохранить".

← →
Ega23 © (2010-12-28 13:07) [29]

> Не-не-не, Дэвид Блэйн. Я предлагаю другой сценарий.

см. [25], я просто забыл этот момент описать.

← →
Вариант (2010-12-28 13:08) [30]

> DiamondShark © (28.12.10 12:55) [28]
> Я кликнул запись, у меня открылась модальная форма со свежей
> записью, я изменил половинну полей, и только потом пошёл
> курить/обедать/какать/пиво пить А потом вернулся и нажал "Сохранить".

Ну вот кроме после потом пошел от ниже приведенного не увидел разницы (что и там возможно).... (Посты о блокировках и прочем пока не рассматриваю)

> Ega23 © (28.12.10 11:37) [22]

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

PS:
Для одинакового прочтения
Я понял
> отредактировал, либо вообще отмену нажал
как отредактировал и сохранил, либо отмену нажал

← →
12 © (2010-12-28 13:08) [31]

> DiamondShark © (28.12.10 12:55) [28]

> Я кликнул запись, у меня открылась модальная форма со свежей
> записью, я изменил половинну полей, и только потом пошёл
> курить/обедать/какать/пиво пить.
> А потом вернулся и нажал "Сохранить".

Вот и именно,
я делал так: В обычном контрле есть что было, в новом (Форме для редактирования) что стало, а перед записью получаем новые данные в НД.

Соответственно, имеется что поменялось мной, что не мной, что вообще не поменялось.

← →
Ega23 © (2010-12-28 13:11) [32]

> Потому что появилась явно более обобщённая и удобная модель
> data binding, в которой нет разницы между ДБ и не-ДБ контролами,
> а источником данных может быть не только датасет, но и
> любой объект вообще.

Ну TDataSet, собственно, это всего лишь абстрактный класс. Вполне можно написать TXMLDataSet, статья с Getting Started где-то тут на сайте лежит (древняя, правда, но сути не меняет).
А из DBAware использовал только DBGrid (только для отображения). И то не родной.

← →
Игорь Шевченко © (2010-12-28 13:21) [33]

Use Oracle Forms, Luke

← →
Anatoly Podgoretsky © (2010-12-28 13:31) [34]

> А, ну да, это тоже. Забыл написать. Типа "Эта запись редактируется
> Васей Пупкиным с рабочей станции Workstation".
> <Цитата>

Телефон такой то, палка стоит в кладовке.

← →
Kerk © (2010-12-28 13:34) [35]

> Игорь Шевченко © (28.12.10 13:21) [33]
>
> Use Oracle Forms, Luke

Как Oracle Forms позволяет взаимных блокировок избежать?
В свое время задолбался с этим.

← →
Petr V. Abramov © (2010-12-28 13:38) [36]

> DiamondShark © (28.12.10 12:51) [27]
>
>
> > А пока ты их редактируешь, на них должна быть блокировка
> > поставлена,
>
> Привет^Wпрощай масштабируемость.
>

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

← →
vuk © (2010-12-28 14:18) [37]

to Petr V. Abramov © (28.12.10 13:38) [36]:

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

Именно. Ибо нефиг. Непротиворечивость и целостность данных - важнее.

← →
Inovet © (2010-12-28 14:49) [38]

> [29] Ega23 © (28.12.10 13:07)
> см. [25], я просто забыл этот момент описать.

> [25] Ega23 © (28.12.10 11:53)
> "Эта запись редактируется Васей Пупкиным с рабочей станции
> Workstation"

Статус: отошёл какать, после обедать.

← →
Ega23 © (2010-12-28 14:58) [39]

> Статус: отошёл какать, после обедать.

Не вижу причин, почему нельзя реализовать мессенджер, если такой присутствует в ТЗ.

← →
Petr V. Abramov © (2010-12-28 15:19) [40]

> Ega23 © (28.12.10 14:58) [39]
>
>
> > Статус: отошёл какать, после обедать.
>
>
> Не вижу причин, почему нельзя реализовать мессенджер, если
> такой присутствует в ТЗ.
>

(только никому не говори). в субд, на которой сидит Влад, нету штатных средств узнать, кто заблокировал запись.

← →
KSergey © (2010-12-28 15:29) [41]

> Ega23 © (28.12.10 14:58) [39]
> > Статус: отошёл какать, после обедать.
> Не вижу причин, почему нельзя реализовать мессенджер

Мессенджер к унитазу?

Если честно, я как-то из всей темы так и не понял проблем с DB-aware компонентами как таковыми. Помнится основная беда с ними была в том, что они упорно лезли сохранить значения в БД когда им вздумается. Но создание отдельного DataSet, чтение в него единственной записи, после отрывание этого DataSet от объекта DBConnection (это в ADO-объектах) - и редактируй себе на здоровье!

← →
Inovet © (2010-12-28 15:29) [42]

> [39] Ega23 © (28.12.10 14:58)
> > Статус: отошёл какать, после обедать.
>
> Не вижу причин, почему нельзя реализовать мессенджер, если
> такой присутствует в ТЗ.

Можно ещё автоматически, как во всяких QIP, чтобы по времени неактивности статус менялся, ну и номер телефона с палкой, как АП предложил.

← →
Ega23 © (2010-12-28 15:35) [43]

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

Всё настраивалось.

← →
12 © (2010-12-28 15:46) [44]

Веселится и ликует весь народ :)
и все есть в Субд которую использует Влад

проблема решена (вернее, способ временного обхода выбран)
Всем спасибо.

← →
Ega23 © (2010-12-28 16:25) [45]

> Можно ещё автоматически, как во всяких QIP, чтобы по времени
> неактивности статус менялся, ну и номер телефона с палкой,
> как АП предложил.

Ты даже себе не представляешь, что вояки в ТЗ пишут. Например, для одного серьёзного объекта в перечне типов АРМ был "АРМ контролёра смены". Такой "особист-контрразведчик" (с), который как раз смотрит, чтобы обычные операторы не отвлекались от службы.
И таки да, активность мыши-клавы a-la QIP отслеживалась.
Любой каприз клиента за его деньги.

← →
Jeer © (2010-12-28 17:06) [46]

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

← →
Jeer © (2010-12-28 17:08) [47]

Я даже как-то уже и не пойму - как же мне удавалось в эпоху фокспро "разруливать" до сотни пользователей в back-office приложении ?

← →
DiamondShark © (2010-12-28 17:40) [48]

> Я даже как-то уже и не пойму - как же мне удавалось в эпоху
> фокспро "разруливать" до сотни пользователей в back-office
> приложении ?

Прямо скажем, хреново удавалось.
Но там локи можно было руками контролировать.

← →
DiamondShark © (2010-12-28 17:44) [49]

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

Ну, это как в том анекдоте: "Идите нафиг, мыши. Я не тактик, я стратег".

← →
KSergey © (2010-12-28 17:46) [50]

> Ega23 © (28.12.10 15:35) [43]
> Всё настраивалось.

Тогда я и вовсе не понимаю что за проблемы обсуждаются.

← →
Ega23 © (2010-12-28 17:52) [51]

> Тогда я и вовсе не понимаю что за проблемы обсуждаются.

Да я сам толком не пойму.
Что-то типа
- DBAware - гавно!
- Ты просто не умеешь их готовить!

to Jeer © (28.12.10 17:06) [46]:

> Т.е. чтение записи на редактирование с ее "отпуском" , затем
> редактирование в ней чего душе угодно, затем, перед записью,
> захват записи и сравнение времени последнего редактирования
> и времени попытки записи - это нонсенс ?

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

to DiamondShark © (28.12.10 17:44) [49]:

> Ну, это как в том анекдоте: "Идите нафиг, мыши. Я не тактик,
> я стратег".

А какой смысл решать техническими средствами организационные вопросы?

> А какой смысл решать техническими средствами организационные
> вопросы?

А это есть частое заблуждение, которым многие (да и я сам, чё скрывать-то) грешат. Всегда хочется, хотя бы ради искусства, чтобы "программа приняла вид лома с кучей настраиваемых шарниров". А лучше фреймворк написать.
А заказчику не нужна "автоматическая обрывалка ушей оператору", ему проще человека специального нанять. Или лучше оператора штрафовать за косяк.

И потом начинаются изгаления по распознаванию введённого текста.
Как сделать, чтобы программа поняла, что "Рога и Копыта Российской Федерации", "Рога и Копыта РФ" и "Poгa и Koпытa PФ" - одна и та же организация с одним ID.
А не надо делать, надо оператора покарать за такой ввод.

← →
_Юрий (2010-12-28 20:02) [54]

На мой взгляд, проблема в том, что DBControl"ы требуют построения логики приложения на датасетах. А в сколько нибудь серьезном проекте логика должна базироваться на объектах, иначе начнется бардак и китайский код.
Безусловно, таких приложений дофига, но смотреть на них без слез обычно невозможно.
Связь "контрол - датсет" избыточна, она приводит к дурной архитектуре. Контролу достаточно объекта.

to _Юрий (28.12.10 20:02) [54]:

> На мой взгляд, проблема в том, что DBControl"ы требуют построения
> логики приложения на датасетах

У нас вот логика в БД живет. А в датасетах - данные.

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

Критерий серьезности, конечно же стоит озвучить.

← →
_Юрий (2010-12-28 20:09) [56]

> vuk © (28.12.10 20:06) [55]

> У нас вот логика в БД живет. А в датасетах - данные.

Мы про программы на Delphi говорим, а не на MSSQL

> Критерий серьезности, конечно же стоит озвучить.

Размер

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

А тебе в любом случае какой-то адаптер придётся писать. От этого никуда не денешься. С поддержкой нотификации, с позиционированием, с ... В общем DataLink (не путать с TDataLink). Можно написать свой, с шахматами и поэтессами. Можно взять готовый, типа TDataSet. Можно взять ещё какой-то готовый.
Выбор складывается из многих вещей, в частности - целесообразность и скорость разработки.
Только и всего.

> Мы про программы на Delphi говорим, а не на MSSQL

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

to _Юрий (28.12.10 20:09) [56]

> Мы про программы на Delphi говорим, а не на MSSQL

Мы говорим про построение логики работы с данными.

> Размер

Размер чего? Сколько этого "чего" должно быть, чтобы была "серьезность"?

← →
_Юрий (2010-12-28 20:49) [60]

> Ega23 © (28.12.10 20:12) [58]

> А зачем?

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

> vuk © (28.12.10 20:17) [59]

> Мы говорим про построение логики работы с данными.

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

> Размер чего?

количество сущностей предметной области.
> Сколько этого "чего" должно быть, чтобы была "серьезность"?

приблизительно 17.

> DiamondShark © (28.12.10 17:44) [49]
>
>
> > если куча народу ломится редактировать одно и тоже, проблема
> > организационная, и создавать автоматизированный бардак
> безблагодатно
>
> Ну, это как в том анекдоте: "Идите нафиг, мыши. Я не тактик,
> я стратег".
>

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

> Petr V. Abramov (28.12.2010 21:00:01) [61]

Бардак автоматизировать не удается!

> Anatoly Podgoretsky © (28.12.10 21:10) [62]
>
> > Petr V. Abramov (28.12.2010 21:00:01) [61]
>
> Бардак автоматизировать не удается!

ну это ты зря, возьми любое внедрение ERP :)
долго, но успешно :)

> Petr V. Abramov (28.12.2010 21:14:03) [63]

Это лишь горькое подобие, а не автоматизация бардака.

_Юрий (28.12.10 20:49) [60]

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

Я тоже переболел в свое время объектами и кустарным ORM - где-то удобно, где-то нет, но не серебряная пуля и не панацея ни разу. Писать больше - это сразу заметно, а выгоды с наследованиями и реюзабельностью кода не видно.
Особенно забавно иногда смотрится в книжках пример тех самых объектов - вот мы заполняем коллекцию из базы данных, вот у нас потом по этой коллекции выполняются какие-то итераторы, вот как мы ловко и красиво стреляем из пулемета^W^W^Wзаписываем эту коллекцию обратно в базу, да еще при этом следим за непротиворечивостью....

Серверную процедуру написать на порядок проще, а выполняться она будет на несколько порядков быстрее. И споровождать ее тоже проще, чем тонну кода с коллекциями, итераторами и прочими наследованиями сущностей предметной области.

> Anatoly Podgoretsky © (28.12.10 21:59) [64]
>
> Это лишь горькое подобие,

ну не спорю, автоматизированный сферический в вакууме затмит венеру милосскую без рук :)

> Petr V. Abramov (28.12.2010 22:30:06) [66]

Венера венец бардака, даже руки обломали.

> Серверную процедуру написать на порядок проще, а выполняться
> она будет на несколько порядков быстрее. И споровождать
> ее тоже проще, чем тонну кода с коллекциями, итераторами
> и прочими наследованиями сущностей предметной области.
>

оно да, но клиентские процедуры-то пишут индусы с китайцами, причем, слава Б-гу, удаленно. ты хочешь, чтоб эта орава от нефиг жрат через нашу территорию кинулась?
> Anatoly Podgoretsky © (28.12.10 23:06) [67]
>
> > Petr V. Abramov (28.12.2010 22:30:06) [66]
>
> Венера венец бардака, даже руки обломали.
>

ей, вроде б как именно по этому поводу, замуж выйти пришлось Ж)

← →
имя (2010-12-28 23:27) [69]

Удалено модератором

← →
имя (2010-12-28 23:31) [70]

Удалено модератором

← →
имя (2010-12-28 23:44) [71]

Удалено модератором

to _Юрий (28.12.10 20:49) [60]:

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

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

> Если логики на клиенте нет, то почему бы и нет.

Логика - это не клиентское дело. Клиенты могут случиться разные и на каждом логику заново реализовывать - это криво. И чем "ближе" логика к данным живет, тем лучше.

> приблизительно 17.

Ага. Теперь буду знать. :)

← →
имя (2010-12-29 00:08) [73]

Удалено модератором

Уходя от DBAware, зашился. Что можно мне посоветовать? Найти похожие ветки