Delphi 2005

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

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

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

> [159] Sergey_Masloff (07.12.04 12:22)

> Правда куда нам до украины но хоть что-то.

:))))
Предлагаю. Расскажи о своей системе:
1. О среднем количестве сущностей (максимальное, прирост в год)
2. О количетве пользователей.
3. О критическом времени запроса
4. О интенсивности обновления данных (добавления)

О себе:
Система бухучета купноотпотового превозчика с простой структурой данных и сложной логикой.
1. Максимально расчетное кол-во сущностей - до 3 млн. Т.к. система бухучета, то цикл годовой (потом в архив). Т.е. за год 3 млн не набираем.
2. До 20
3. Не оговаривается, но оперативные запросы (частовызываемые) - не более 20 сек. Есть по несколько десятков минут не из-за сложности, а из-за ошибок, но т.к. они редки - руки не доходят.
4. Самый критический случай - массоый ввод документо одним из пользователей (порядка 1-2 в сек, всего до 1000) при том, что остальная система должна ворочаться.

Достоинства, что логика реализуется в сриптовом языке толстого уровня. Язык оперирует в рамках определенных условий, которые гарантируют:
1. Целостность.
2. Атомарность транзаций.
3. и пр.
Более сложные вещи реализуем на дельфи.

← →
}|{yk © (2004-12-07 12:29) [162]

Ну как это? А факт? План конечно занимает немного, а факт получается изо всевозможных учетных систем. Но обрабатывается (консолидируется) уже самой Comshare MPC.

← →
by © (2004-12-07 12:30) [163]

Я читал о том что в .NET Framework 1.2 MS вводят поддержку ORM через свои ObjectSpaces.
http://www.rsdn.ru/article/dotnet/objectspaces.xml
Они видят в этом перспективу, но пока это в стадии разработки так как достаточно сложно.

← →
vuk © (2004-12-07 12:30) [164]

to Sergey_Masloff:
>Или и по этому вопросу возражения имеются?
Я думаю, найдутся. Правда не я. :o) Просто у кого-то на первом плане эффективность разработки, а не эффективность функционирования. От этого и споры.

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

> [164] vuk © (07.12.04 12:30)

> Просто у кого-то на первом плане эффективность разработки

Ну и что здесь такого?
Не будет эффективной разработки - не будет ни эффективного функционирования, ни неэффективного функционирования. Логично?

← →
euru © (2004-12-07 12:32) [166]

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

По вопросу? Имеются. Основная задача (точнее, одна из основных задач) - это эффективная обработка данных. :)

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

← →
by © (2004-12-07 12:34) [167]

vuk © (07.12.04 12:30) [164]
Проблема действительно в приоритетах. Если приоритетна скорость вывода продукта на рынок, а не максимальная производительность, то конечно через ECO и прочие ORM можно быстрее набросать.
Тем более что производительность через объекты вполне может устроить.

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

> СУБД будет тратить своё процессорное время на обработку
> этих данных, задерживая остальные запросы в очереди.

Вот, золотые слова.
У меня половина зпросов на клиенте сделана. Смею вас заверить, что зная логику можно создать более оптимальный запрос, чем это делает серверный оптимизатор. Тебе не нужно собирать статистику: ты знаешь какая особенность данных и как их лучше обрабатывать. Merge, hash или loop. На это не тратится. Время.

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

← →
vuk © (2004-12-07 12:39) [169]

to Суслик © (07.12.04 12:31) [165]:
>Не будет эффективной разработки - не будет ни эффективного
>функционирования, ни неэффективного функционирования.
Это из серии "Ну и что, что тормозит? Зато смотрите как круто мы код генерим!"? :o)

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

> [169] vuk © (07.12.04 12:39)

Иногда это важнее? Не находишь?

Да и торможение поняте относительное. Если люди могут делать работу, на которую тратили до нескольких дней, за 10 минут, то им по фигу 10 это минут, или 0.001 секунд.

← →
Petr V. Abramov © (2004-12-07 12:45) [171]

> vuk © (07.12.04 12:30) [164]
> Просто у кого-то на первом плане эффективность разработки, а
> не эффективность функционирования. От этого и споры.
Насчет эффективности разработки тоже можно поспорить :) С тобой не буду :)

← →
vuk © (2004-12-07 12:45) [172]

to Суслик © (07.12.04 12:35) [168]:
>Смею вас заверить, что зная логику можно создать более
>оптимальный запрос, чем это делает серверный оптимизатор.
И как это связано с используемой архитектурой? Кстати, иногда даже зная логику не получается эффективно написать не изучая планы запросов.

>Прикол в том, что 99 процентов времени тратится на анализ
>запроса, а не на выполнение.
О! А процедура анализируется и оптимизируется один раз. В MSSQL - при первом запуске.

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

> С тобой не буду :)

во-во, а я ввязался.

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

> О! А процедура анализируется и оптимизируется один раз.
> В MSSQL - при первом запуске.

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

> И как это связано с используемой архитектурой?

Не понятно? Можно не возлагать на сервак все обязанности. Именно в этом.

← →
Petr V. Abramov © (2004-12-07 12:51) [175]

> Суслик © (07.12.04 12:46) [173]
> во-во, а я ввязался.
Да не, я-то имел в виду, что не с vuk © у меня предмет спора отсутсвует :)

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

> [175] Petr V. Abramov © (07.12.04 12:51)

Облажался, бывает :)))

← →
euru © (2004-12-07 12:54) [177]

>vuk © (07.12.04 12:45) [172]
>О! А процедура анализируется и оптимизируется один раз. В MSSQL - при первом запуске.

Всё-таки, как бы ни была оптимизирована процедура, на её выполнение всё равно понадобится некоторое время. И мы снова возвращаемся к [166].

← →
Petr V. Abramov © (2004-12-07 12:54) [178]

Petr V. Abramov © (07.12.04 12:51) [175]
> Суслик © (07.12.04 12:46) [173]
> во-во, а я ввязался.
Да не, я-то имел в виду, что с vuk © у меня предмет спора отсутсвует :)

← →
Petr V. Abramov © (2004-12-07 12:55) [179]

Petr V. Abramov © (07.12.04 12:51) [175]
Да не, я-то имел в виду, что с vuk © у меня предмет спора отсутсвует :)

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

> [179] Petr V. Abramov © (07.12.04 12:55)

ну тогда еще парочку постов, чтобы "отсутсвует" поправить :)))

← →
Sergey_Masloff (2004-12-07 12:59) [181]

euru © (07.12.04 12:54) [177]
>Всё-таки, как бы ни была оптимизирована процедура, на её >выполнение всё равно понадобится некоторое время. И мы снова >возвращаемся к [166].
Если эта процедура для своей работы обращается к данным которых нет у клиента (а это обычно так и бывает - справочники там, тарифные таблицы - да мало ли что) то на дерганье сетевого стека уйдет на порядки больше времени.

← →
Petr V. Abramov © (2004-12-07 13:03) [182]

Суслик © (07.12.04 12:29) [161]
> Предлагаю. Расскажи о своей системе:
....
> О себе:
....

Если вероятность конфликта за бух/складские остатки, свободные машины и т.п. низкая, это можно на 1С сделать (лет 5 назад нельзя было, техника была слабая). Если вероятность высокая - сразу забудешь про оптимистические блокировки и уберешь логику на сервер

← →
Petr V. Abramov © (2004-12-07 13:06) [183]

> Суслик © (07.12.04 12:56) [180]
пардон, "отсутствует" :))))))

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

Суслик ©
Я твой пост не замалчиваю. Но написать не могу - конфиденциально все :(
Примерно так:
1) На порядок больше у нас (кроме того на каждую сущность хранится история изменений но это я не считаю так как в работе не используется - только для разборов полетов)
2) По самым скромным оценкам на 2 порядка больше у нас
3) Так же. В смысле критично чтобы устраивало пользователя. С секундомером не меряем.
4) Работа по добавлению (и изменению) интенсивная - для всех пользователей наш софт основной инструмент, то есть скажем 50% рабочего времени они там манипулируют.
95% логики - сервер.

Вот вроде секретов не раскрыл но суть передал. Я к чему - работать можно, как практика показывает, ничто не следует воспринимать как догму ;-)

← →
euru © (2004-12-07 13:15) [185]

>Sergey_Masloff (07.12.04 12:59) [181]

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

← →
Sergey_Masloff (2004-12-07 13:20) [186]

euru © (07.12.04 13:15) [185]
Да знаю я что буферизуются. Итак имеем: На сервере приложений огромный массив неактуальных данных в памяти. На клиенте - на каждый чих необходимость лазить за данными на сервер приложений. На сервере имеем необходимость по второму разу контролировать потенциально недостоверные данные. Я праильно уловил суть? ;-)

← →
euru © (2004-12-07 13:56) [187]

>Sergey_Masloff (07.12.04 13:20) [186]
1. Для того чтобы буферизация была адекватна актуальности данных, имеется 3 стратегии буферизации: буферизация всей таблицы, буферизация по определённым ключевым полям и буферизация одной записи.
2. На клиенте вообще ничего происходит. Его задача передать серверу приложений запрос и отобразить результат. Все проблемы разруливает сервер приложений, и делает это он один раз.

← →
Суслик © (2004-12-07 13:59) [188]

> [184] Sergey_Masloff (07.12.04 13:07)

Ну раз такие объемы, то спорить не буду.
Как я говорил - всему свой инструмент.

> [182] Petr V. Abramov © (07.12.04 13:03)

У нас не только опт. блок. есть. Есть и пессимистические. Выбор - после оценки вероятности конфликтов.

← →
Sergey_Masloff (2004-12-07 14:03) [189]

euru © (07.12.04 13:56) [187]
>1. Для того чтобы буферизация была адекватна актуальности >данных, имеется 3 стратегии буферизации: буферизация всей >таблицы, буферизация по определённым ключевым полям и >буферизация одной записи.
Ну какая стратегия. Я считаю формулу тариф по совокупности условий хочу взять из справочника. Беря данные с сервера приложений никакая стратегия не гарантирует мне что данные те же что в БД. Или триггер в БД должен на каждый чих оповещать все сервера приложений. Что очень накладно видимо?

> Беря данные с сервера приложений никакая стратегия не гарантирует
> мне что данные те же что в БД.

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

← →
Sergey_Masloff (2004-12-07 14:09) [191]

Суслик © (07.12.04 13:59) [188]
>Ну раз такие объемы, то спорить не буду.
Ну и зря. Лучше спорить - когда для спора ищешь аргументы то можно и для себя многое по полочкам разложить. Я например пытался по "твоей" стратегии работать. Есть проектик но что-то то ли я недопроектировал то ли просто сала в голове не хватило. Вобщем-то работает оно работает но в поддержке тяжеловат вышел. Но в этом значительная часть моей вины так как по всем показателям как раз для такой модели задача подходила ;-)

> [189] Sergey_Masloff (07.12.04 14:03)

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

> [191] Sergey_Masloff (07.12.04 14:09)

> Я например пытался по "твоей" стратегии работать

Это о чем? Какой моей?

>Sergey_Masloff (07.12.04 14:03) [189]

Выдержка из SAP Help:

If a buffered table is modified, it is updated synchronously in the buffer of the application server from which the change was made. The buffers of the whole network, that is, the buffers of all the other application servers, are synchronized with an asynchronous procedure.

Entries are written in a central database table (DDLOG) after each table modification that could be buffered. Each application server reads these entries at fixed time intervals.

> [191] Sergey_Masloff (07.12.04 14:09)

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

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

← →
Sergey_Masloff (2004-12-07 14:21) [196]

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

> [196] Sergey_Masloff (07.12.04 14:21)

Ты бы анкету прописал - возраст интересно было бы знать.

Не понял:

> 161] Суслик © (07.12.04 12:29)
> 1. О среднем количестве сущностей (максимальное, прирост
> в год)
> 2. О количетве пользователей.
> 3. О критическом времени запроса
> 4. О интенсивности обновления данных (добавления)

> 1. Максимально расчетное кол-во сущностей - до 3 млн. Т.к. система бухучета, то цикл годовой (потом в архив). Т.е. за год 3 млн не набираем.
> 2. До 20

> [184] Sergey_Masloff (07.12.04 13:07)

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

Т.е. сущностей - до 300 тыс. а пользователей до 1-го? :( Крута.

← →
Sergey_Masloff (2004-12-07 14:56) [200]

Думкин © (07.12.04 14:32) [199]
Когда на порядок больше это умножать на 10 надо а не делить ;-) Кто из нас математик? ;-)

Суслик © (07.12.04 14:23) [198]
>Ты бы анкету прописал - возраст интересно было бы знать.
Да не люблю я эти анкеты. У меня к ним идеосин... не помню вобщем то что у А.Подгорецкого к голубому цвету ;-) Когда
А так секретов нет возраст христа 33.

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