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

← →
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 - гавно!
- Ты просто не умеешь их готовить!

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

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

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

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

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

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

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

← →
Ega23 © (2010-12-28 18:27) [53]

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

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

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

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

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

← →
vuk © (2010-12-28 20:06) [55]

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

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

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

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

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

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

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

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

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

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

Размер

← →
Ega23 © (2010-12-28 20:09) [57]

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

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

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

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

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

← →
vuk © (2010-12-28 20:17) [59]

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.

← →
Petr V. Abramov © (2010-12-28 21:00) [61]

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

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

← →
Anatoly Podgoretsky © (2010-12-28 21:10) [62]

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

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

← →
Petr V. Abramov © (2010-12-28 21:14) [63]

> 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, зашился. Что можно мне посоветовать? Найти похожие ветки