Delphi 2005

← →
by © (2004-12-06 16:31) [80]

Суслик © (06.12.04 16:27) [78]
А свой ORM это много человеко-часов ((
И не факт что будет как надо. Фаулер рекомендует покупать )))

← →
Суслик © (2004-12-06 16:33) [81]

> [75] Sergey_Masloff (06.12.04 16:19)
> Да написали бы. Была б логика а реализовать ее хоть на счетах
> можно.

Как мне кажется разрабатывать в рамках эволюционного подхода все-таки проще в рамках языка, типа дельфи, ++ и пр, а не в рамках процедурного языка, коим, например, являтется T/SQL.
Рефакторинг проще делается в языках с компилятором. Многие моменты поправит за тебя компилятор, просто когда не сможет скомпилить как-нибудь конструктцию. В T/SQL все-таки сложнее.

← →
by © (2004-12-06 16:34) [82]

Sandman25 © (06.12.04 16:31) [79]
Та не боится его никто. Просто рекомендации лучших собаководов (Фаулер и иже с ними) говорят что объекты это лучшее решение, а если вас угораздило работать с БД, то используйте ORM. При этом навороченные СУБД получаются в роли бедных родственников, но зато переносимость с платформы на платформу высокая.

← →
DiamondShark © (2004-12-06 16:35) [83]

> Я бы посмотрел, как на sql сервере написали скрипт поддерживающих
> логику нашего счета-фактуры.

Легко.

← →
Суслик © (2004-12-06 16:36) [84]

> [79] Sandman25 © (06.12.04 16:31)

Я его не боюсь - я регулярно пишу отчеты.
Он проще, кончено, если ты знаешь особенности оптимизатора. Меня он задалбывает иногда. То план выберет не тот, то еще чего.

> [80] by © (06.12.04 16:31)

Да я уже понял, что ты Фаулера начитался. Хорошая книга.
А вообще все зависит от условий. У нас были условия писать такую штуку. 4 года работаем. Пока не пожалели. У кото-то могут быть другие условия. Задай мне писать новый проект месяца на 3-4, не в жизнь не связался бы со своими разработками - только штатные. Но для долгоиграющий проектов мне такой подход нравится вполне.

← →
DiamondShark © (2004-12-06 16:39) [85]

> не в рамках процедурного языка, коим, например, являтется
> T/SQL.

А я, несчастный, всю жизнь его декларативным считал...

← →
Sergey_Masloff (2004-12-06 16:40) [86]

by © (06.12.04 16:34) [82]
>При этом навороченные СУБД получаются в роли бедных >родственников,
;-)
>но зато переносимость с платформы на платформу высокая.
Это легенды.

Как хорошо сказал Т.Кайт - в конце концов реляционные СУБД это единственное что осталось неизменным в быстроразвивающемся мире IT в последние 25 лет и позиций не теряет. Основой чему является отличная математическая проработка технологиии и отлаженные за десятилетия механизмы реализации. Так что думайте сами решайте сами.

Если есть возможность комбинировать - можно комбинировать. Если думать о сосредоточении в одном месте логики - я за СУБД.

Хотя еще раз следует уточнить - "Определяет задача" (с) Суслик

← →
Danilka © (2004-12-06 16:41) [87]

[81] Суслик © (06.12.04 16:33)
> Многие моменты поправит за тебя компилятор, просто когда
> не сможет скомпилить как-нибудь конструктцию. В T/SQL все-таки
> сложнее.

PL/SQL с компилятором. Все ошибки сразу показывает. :))
Для T/SQL, говорят, неплохой отладчик ХП есть, правда сам с ним не пробовал работать, но, говорят, очень удобный.

← →
Суслик © (2004-12-06 16:42) [88]

> [83] DiamondShark © (06.12.04 16:35)
> Легко.

Если описание будет.

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

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

Поэтому, либо неоднократный рефакторинг и эволюция развития, либо ноль.

Я не спорю, что на sql можно написать что угодно (в рамках разумного). Но переработка, повторное использование кода и пр. в нем сложнее. Будешь спорить?

← →
by © (2004-12-06 16:43) [89]

Суслик © (06.12.04 16:36) [84]
Да, если проект на длительное время разработки, то ориентироваться на что-то чужое стремно. Конечно если есть специалисты которые могут реализовать свое.

← →
Суслик © (2004-12-06 16:43) [90]

> [85] DiamondShark © (06.12.04 16:39)
>
> А я, несчастный, всю жизнь его декларативным считал...

ладно, ладно - не заводись :)
Я же не столько книжек прочел :)
За информацию спасибо.

← →
Суслик © (2004-12-06 16:46) [91]

Чтобы не скатываться в оффтоп вопрос по сабжу:

видел ли кто нормальные (или любые) книги по delphi 2005.

← →
Sandman25 © (2004-12-06 16:47) [92]

[82] by © (06.12.04 16:34)

Фаулер и иже с ними провозгласили, что если вас заботит быстрота кода, то экстремальное программирование не для вас. Основная задача - упрощение разработки, упрощение для человека. Таким образом большинство приложений, работающих с большими объемами данных (подавляющее большинство приложений БД) и с критичными требованиями к скорости, требуют другого подхода.
Реализовывать в объектах то же, что выполняется в хранимой процкедуре на 1000 строк, я бы никому не советовал.

← →
DiamondShark © (2004-12-06 16:48) [93]

> Суслик © (06.12.04 16:17) [74]
>
> > [71] DiamondShark © (06.12.04 16:01)
> > 3000000 записей для хорошего SQL-сервера -- не объём.
> > А для любой ОО-нашлёпки -- смерть.
>
>
> Хотелось бы с этим не согласится.
>
> Я полагаю, что все зависит от подхода и задач. С точки зрения
> построения отчетов я полагаю, что sql лучше всего. С точки
> зрения insert\update\delete, то с твоим утверждением не
> могу до конца согласится. Важно понимать интенсивность таких
> операций.
>
> Мы комбинируем два подхода. Пока проблем нет.

Этокакэто?

Я говорю вообще о манируляции данными, представленными в реляционной модели.
Что тут комбинировать? Комбинируй, не комбинируй, а схема всегда останется одной: Реляционная модель -> нашлёпка -> другая модель -> манипуляция -> нашлёпка -> реляционная модель.

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

← →
Суслик © (2004-12-06 16:53) [94]

> [93] DiamondShark © (06.12.04 16:48)

> Этокакэто?

Сторона БД (ms sql server)
1. Есть реляционка. Опустим с точки зрения простоты структуру.
2. Есть метаданные на сервере.
3. Есть часть mapper на сервере.
4. Есть интрументы управления блокировками (оптимистическими и пессимистическими). Они доступны объектоной модели.

Сторона толстого клиента
1. Есть метаданные на клиенте
2. Есть mapper на клиенте. Его можно так назвать - доmapper, т.е. доделывает то, что не доделал mapper на сервере.
3. Есть объектная модель с логикой.
4. Интерфейс.

Это один подход. Тут в регулярной работе я не сталкиваюсь с sql.

С точки зрения отчетов обращение к sql есть. Именно на нем пишутся все запросы.

Это я имел в виду под комбинацией: для транзакций без sql, для отчетов - sql.

← →
by © (2004-12-06 16:55) [95]

Sandman25 © (06.12.04 16:47) [92]
С таким определением полностью согласен. Наверное если скорость не на первом месте, тогда программирование через модели - очень хороший способ.

← →
DiamondShark © (2004-12-06 17:02) [96]

> Суслик © (06.12.04 16:42) [88]
>
> > [83] DiamondShark © (06.12.04 16:35)
> > Легко.
>
>
> Если описание будет.

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

> А если нужно придумать с заведо известной необходимостью
> неоднократного рефакторинга? Итерации, эволюция...

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

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

> Поэтому, либо неоднократный рефакторинг и эволюция развития,
> либо ноль.

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

← →
DiamondShark © (2004-12-06 17:07) [97]

> Суслик © (06.12.04 16:53) [94]

А, ну понял.

Это как раз то, про что говорил Сергей Маслов: сервер используется как хранилище.

Обидно. Зачем здесь MSSQL с его мощнейшими возможностями манипуляции данными, если они на 99% не задействованы?

Выкинутые на ветер деньги...

← →
Суслик © (2004-12-06 17:08) [98]

> DiamondShark © (06.12.04 17:02) [96]

Сложно спорить. Думаю, что мерилом эффективности должно служить то, сколько времени продукт используется успешно. У меня и у тебя (судя по всему) с этим все в порядке.

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

> DiamondShark © (06.12.04 17:07) [97]

> Это как раз то, про что говорил Сергей Маслов: сервер используется
> как хранилище.

в общем-то да, ты прав.

> Обидно. Зачем здесь MSSQL с его мощнейшими возможностями
> манипуляции данными, если они на 99% не задействованы?

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

К тому же запросы - все отчетв в нем.

← →
DiamondShark © (2004-12-06 17:33) [100]

> Суслик © (06.12.04 17:08) [98]
> Сложно спорить. Думаю, что мерилом эффективности должно
> служить то, сколько времени продукт используется успешно.

Я категорически против такого мерила. По общефилософским соображениям ;)

Хотя, не жалуюсь. Используется. И что меня больше всего радует -- используется без меня.

> Суслик © (06.12.04 17:11) [99]
> Как говорили умные люди, не упускайте возможность юзать
> манагер системных транзаций. Для этого и юзаем.

Да при чём тут манагер транзакций!
А, ладно...

← →
DiamondShark © (2004-12-06 17:36) [101]

Вспомнилось:

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

← →
Суслик © (2004-12-06 17:43) [102]

> [100] DiamondShark © (06.12.04 17:33)

> Да при чём тут манагер транзакций!
> А, ладно...

Как при чем? Ты мне предлагаешь его самому написать? :) Я против...
Есть сервер, почему бы его не юзать...

> Я категорически против такого мерила.

Я тоже был раньше против. И тоже по тем же причинам. Но вырос :))

← →
DiamondShark © (2004-12-06 17:54) [103]

> Есть сервер, почему бы его не юзать...

Ну да. Для манипуляции данными. Без промежуточных преобразований.

> Но вырос :))

Ню-ню ;)

← →
Суслик © (2004-12-06 18:01) [104]

> [103] DiamondShark © (06.12.04 17:54)

Ладно, опустим общие слова, которые ясны любому разработчику баз данные - все на вервере, sql рулит и пр. Можно конкретней?

Есть потребность в интерфейсном вводе документа, который обладает 1-3 уровневыми master-detail с нефиговой логикой зависимостей полей. Грубо говоря - тут поравил, пересчитался весь документ (полей так 200). Там поправил - еще пара сотен. Т. е. есть потребность в интерактивном вводе информации с быстрым откликом системы. Алогоритмы пересчета полей достаточно заумные.

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

← →
Суслик © (2004-12-06 18:45) [105]

Вопрос про книги все-таки остается - видел ли кто-нибудь достойные книги по дельфи 2005?

← →
vuk © (2004-12-06 18:46) [106]

to Суслик © (06.12.04 18:01) [104]:
>Как бы ты реализовал данную возможность?
Пересчет на сервере. У него больше информации о текущем состоянии системы в целом.

← →
DiamondShark © (2004-12-06 18:51) [107]

> Суслик © (06.12.04 18:01) [104]

Такую вещь -- на клиенте.

Но я бы ещё двадцать раз подумал, стоит ли тут применять метафору документа в полном объёме.

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

> [106] vuk © (06.12.04 18:46)
> Пересчет на сервере. У него больше информации о текущем
> состоянии системы в целом.

Я не сомневался, что ответ будет таков.

Т.к. персчет на сервере, значит есть изменение серверных данных, значит должна быть транзакция. Какой уровень изоляции? Полагаю, что нехилый - ближе к serizable - обновление долгосрочное, фантомы и nonrepetable read здесь не нужны.

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

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

Можно использовать временные таблицы, табличные переменные и пр. Т.е. не постить в базу. Если так, то зачем тогда вообще это делать на сервере, если пересчитать объекты до их сохранения можно с равным успехом на клиенте? При том, что в момент сохранения (т.е. краткосрочно) действует пессимистическая блокировка с обязательной проверкой на уровне клиента и на уровне сервера.

> [107] DiamondShark © (06.12.04 18:51)
> Но я бы ещё двадцать раз подумал, стоит ли тут применять
> метафору документа в полном объёме.

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

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

> [110] DiamondShark © (06.12.04 19:04)

> Где тебе там долгосрочные транзакции померещились?

Я вижу хорошо. Спасибо за заботу о моем здоровье :)

Так. Пользователь решил отредактировать документ. Редактировал, редактировал и передумал. Т.е. нужон откат.
Что будешь делать в этом случае? Полагаю либо транзакция, либо временный сброс данных в промежуточные таблицы с сохранением их в основных таблицах в момент подтверждения пользователем сохранения. Есть другой путь?
Во втором случае транзакции может и не нужны. Но это некий наворот, в котором лично у меня нет опыта. Возможно, что это станратный путь решения подобных задач. Я просто не знаю.

Просвети.

> Если так, то зачем тогда вообще это делать на сервере, если
> пересчитать объекты до их сохранения можно с равным успехом
> на клиенте?

Например потому, что для пересчёта может потребоваться большой объем других данных (например, справочники, какие-нибудь реестры, остатки по складу и проч.)
Часть из них может достаточно активно меняться.

> [113] DiamondShark © (06.12.04 19:09)

> Часть из них может достаточно активно меняться.

Что кроется под этой фразой? В процессе пересчета данного документа? Если да, то активное изменение данных можно седалть и при сохранении документа: в процессе рассчета документа такое на фиг не нужно. Пока пользователь не решил сохранить документ - никаких изменений. Да, согласен, что активное изменение связных данных при сохранении можно поручить и процедуре. А можно и не поручать - это не догма.

> Суслик © (06.12.04 19:13) [114]
>
> > [113] DiamondShark © (06.12.04 19:09)
>
>
> > Часть из них может достаточно активно меняться.
>
> Что кроется под этой фразой?

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

to Суслик © (06.12.04 19:00) [108]:
>Ты думаешь есть смысл в том, чтобы держать долгосрочне
>транзации такого уровня?
Никто вообще не собирается держать какие-либо долгосрочные транзакции. Транзакция будет, но только на время изменения данных. Эксклюзивность доступа реализуется блокировками ресурсов на уровне приложения. Если же нужен откат, то тут, на мой взгляд, стоит делать историю изменений с возможностью отката по истории.

> [115] DiamondShark © (06.12.04 19:18)

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

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

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

Да, это медленнее. Зато логика в одном месте.

> [116] vuk © (06.12.04 19:22)

Очень хорошо, что не собираетесь делать долгосрочные транзации. Я и такое видал :)))

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

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

> [118] vuk © (06.12.04 19:27)

> Трудноотслеживаемостью множественных ошибок.

Кто отслеживает? Кто совершает?

Ничего не понятно :))

Если ты (образно говоря) совершаешь ошики, они всегда трудноотслеживаемы. И не важно где - на сервере, на клиенте.

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

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