Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Access or Delphi  [new]
c127
Guest
2 Senin Viktor
Member

>Ну не любяит у нас прогеры, чтобы без гемору

Так получается, что "у них" тоже любят потрахаться. На западе я тоже акцесс в качестве клиента не встречал. Подозрительное единство взглядов.

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

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

Зачем мы спорим? В первом посте Tung написал, что "работал с MSSQL и Delphi". Зачем же ему предлагать сомнительные продукты, которых он еще и не знает, если в он может успешно использовать знакомые продукты.
7 ноя 03, 00:20    [409451]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Senin Viktor писал:

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


Разработчики давно уже в Израиле :(. Поддержки нет.
А у меня - падают. И это не мои базы. Я глубоко уверен, что хороший спец по Access может написать отказоустойчивую базу на mdb. Я сам писал подержку транзакций на Clipper. Но зачем он нужен, этот гемор, если есть готовые решения?

Senin Viktor писал:

Ну не любяит у нас прогеры, чтобы без гемору



===========
vdimas писал:

Сколько открытых рекордсетов с приаттаченным коннекшеном, столько реальных конекшенов и открыто.

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

Не выдавайте свои приемы работы за порочность инструмента.

vdimas писал:

В многоуровневых приложениях, где операции с базой берет на себя средний слой

Все ясно. Еще один любитель создавать себе проблемы. На трехзвенке.
7 ноя 03, 18:02    [409904]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
Cat2 писал:
Не вижу смысла в использовании потоков для выполнения запросов. На мой взгляд, вполне достаточно асинхронного режима выполнения.


Хм... Здесь на форуме меня, порой, откровенно озадачивают "неординарным" подходом. :)
Что ответить?...
1. Создать еще один поток - фигня на постном масле. У меня есть идиома тасков (Tasks) - это объекты-функторы, которые просто пуляешь на исполнение в некий тред, и они становятся себе в очередь этом треде и исполняются. Разработка этой части фреймворка потребовала, ясно дело, небольших усилий, но теперь от проекта к проекту успешно повторно используется. Так что для меня описать задачу, со своими приватными данными и т.д и т.д. - фигня полная.
2. Просто ответь на такой вопрос: что удобнее, написать обыкновенный "человеческий алгоритм", который просто выполнится в соседнем потоке, или реализовывать что-то типа автомата состояний, который действует по событиям асинхронных вызовов? Вопрос не стоит, если надо просто выполнить один запрос и проконтролировать его успешность. А если необходимо выполнять довольно сложные действия, в зависимости от результатов, т.е. использовать довольно "ветвистый алгоритм"? С асинхронностью замучаешься...

автор писал:
Еще один любитель создавать себе проблемы. На трехзвенке.

А кто сказал, что я любитель 3-х звенки? :)
Если предполагается работа в быстрой локальной сети, то, чем тратиться на разработку среднего слоя и покупку сервака под app-сервер, лучше на эти же деньги купить более мощный сервак под DB и сделать клиент-сервер. У клиент-сервера время отклика значительно лучше.
А вот, например, если надо, чтобы приложение адекватно через Dial-Up работало? Или через Web?
Так что, нравится-не нравится, глотай, моя красавица...
7 ноя 03, 20:18    [409947]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
vdimas. Сегодня я вижу, что вчера я отвечал вовсе не данный топик, а на какие-то свои мысли. Иначе зачем я приплел асинхронные запросы?
8 ноя 03, 10:32    [410036]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
2vdimas:
>У каждого потока (thread), обращающегося к базе должен быть свой коннект, и ни в коем случае не стоит использовать один общий из соседнего потока (именно потому, что ADO-объекты thread-safe, т.е. только один тред может одновременно использовать один объект, напр. конект).
....
насколько я понял, вы обращаетесь к базе из того же треда, в котором у вас работает основное GUI??? Да еще держите ПОСТОЯННО один глобальный конекшн открытым?
....
а при долгих запросах у нас приложение-то замирает и даже не прорисовывается... а грид мы показать не можем, пока к нему все запрошенные данные не придут. А все запросы исполняем только последовательно, один за другим


Если поток для работы с данными один, то и смысла нет иметь несколько connections, а в большинстве задач этого вполне достаточно. Так же для объединения потока с GUI - для небольших запросов и быстрого отклика это совершенно нормально. Обычный intranet-oriented подход, который ВЕСЬМА сокращает время разработки при соблюдении критериев качества приложения (удешевляет разработку). А Вы явно с дешевыми заказами не работаете :-)
При большом количестве запросов/долгом времени отклика можно и распараллелить потоки (internet-приложения, например).
Зато при постоянно открытом соединении проще реализовать некоторые вещи типа блокирования документов для редактирования другим пользователем (обсуждалось недавно в MS SQL форуме) и т.д.

>Экспериментально установлено, что если с некоторой базой (именно базой внути инстанса сервака) работает только ОДИН пользователь, то после отключения на некоторое продолжительное время (точно не замерял, что-то около минуты-две), повторное соединие происходит с задержкой (2-3 сек).

А если один пользователь - частая ситуация. Тогда Вы предлагаете заведомо проигрышные варианты !

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

Не надо путать intra и inter- net приложения. Разные архитектурные подходы. Между прочим, в Инет приложении вообще трафик жать надо и т.д.

>Disconnect Your Client Cursor from the Connection for R/O and Long-Use Scenarios

Ну хоть слава богу, я ничего не упустил. Я уж думал про отсоединения connection речь шла. А по поводу Disconnected rescordset (IMHO) сия рекомендация вызвана не столько расходованием ресурсов сервера, сколько попыткой увеличить надежность программ, т.к. всегда можно ожидать в результате некоего глюка (в программе, скажем), что подключенный рекордсет может каким-либо ненужным образом изменить записи в базе. И блокирование записей исключить опять же (при разных моделях блокировки).
Так, в свое время, обязательной рекомендацией для Foxpro 2.6 было: открывать таблицу с возможностью UPDATE ТОЛЬКО для непосредственного выполнения операций с ней, иначе всегда делать USE .. READONLY. Это очень сильно повышало надежность приложения.
8 ноя 03, 15:43    [410133]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
автор писал:
Обычный intranet-oriented подход, который ВЕСЬМА сокращает время разработки при соблюдении критериев качества приложения (удешевляет разработку). А Вы явно с дешевыми заказами не работаете :-)

Елы-палы... Сами подставляетесь.
Причем тут цена? Цена ведь из трудоемкости складывается, так?
И что он сокращает, такой подход, позвольте спросить? Отрезок времени до выхода первой рабочей формы? Потому как такую форму можно просто мышкой "накидать"?
А если стоит задача сократить отрезок времени до ОКОНЧАНИЯ всего проекта, и совершенно фиолетово, когда появится ПЕРВАЯ форма? Понимаешь, от дельфийских компонент заколебешься наследоваться. Т.е. довольно трудоемко компонент писать (относительно простого наследования ради переопределения, скажем, какой-нить мелочи). А я могу наследоваться легко и непринужденно буквально за каждой мелочью. Могу вообще все основные операции в базовые классы запрятать (напр. по работе с сервером). 90% приложения работает само по себе и управляется метаданными. Ручками только всякие drag&drop-ы и прочие неординарности. Для довольно сильного изменения поведения в некотором моменте, встречающемся во всем приложении достаточно "подкрутить" только в одном месте. "Управляемость кода". Слышал такое понятие? Оно напрочь отсутствует там, где формы "рисуются" мышкой, потому как чтобы сделать такую мелочь, как поменять цвет фона или шрифт у всех меток, необходимо прошерстить все 300 и более форм, присутствующие в приложении. :)

автор писал:
Не надо путать intra и inter- net приложения. Разные архитектурные подходы. Между прочим, в Инет приложении вообще трафик жать надо и т.д.

Ты даже не представляешь, насколько хорошо и надежно работают в интра-нет приложения, заточенные под интер-нет.

автор писал:
А если один пользователь - частая ситуация. Тогда Вы предлагаете заведомо проигрышные варианты !

Это уже интересно, клинический случай. Тут уже и на локальной файловой базе не грех приложение сделать. По времени отклика "уделает" любой другой вариант.
9 ноя 03, 11:07    [410374]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
>Причем тут цена? Цена ведь из трудоемкости складывается, так?
И что он сокращает, такой подход, позвольте спросить? Отрезок времени до выхода первой рабочей формы? Потому как такую форму можно просто мышкой "накидать"?

Не совсем, просто не надо самому изобретать велосипед и писать (тестировать) какие-то свои навороты. Накидать мышкой - именно в этом цель удешевления разработки. Сразу не пинать - читайте далее...

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

Не вижу абсолютно ничего сложного - даже мастер есть для автоматического наследования. Руками это занимает на 3 мин. дольше :-))) А наследоваться все равно придется, если, конечно у Вас больше 2 форм и Вам знакомо то самое понятие "Управляемость кода" :-)

>Могу вообще все основные операции в базовые классы запрятать (напр. по работе с сервером). 90% приложения работает само по себе и управляется метаданными. Ручками только всякие drag&drop-ы и прочие неординарности.

Имеет смысл только при написании большой системы объемом более 2 чел/лет (навскидку). Потому что создание и отладка подобного движка - уже около 1-1,5 чел/года. Хотя ... Вы шутя справитесь за месяц :-)))

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

Для этого совершенно необязательно всю логику на сервер перекидывать. Просто при написании клиента надо поменьше пользоваться Copy+Paste а побольше думать об архитектуре приложения и реинжиниринге.

>"Управляемость кода". Слышал такое понятие? Оно напрочь отсутствует там, где формы "рисуются" мышкой, потому как чтобы сделать такую мелочь, как поменять цвет фона или шрифт у всех меток, необходимо прошерстить все 300 и более форм, присутствующие в приложении. :)

Понятие типа слышал, типа даже стараюсь применять ;-)
Достаточно использовать не стандартные компоненты, а их наследники. Все реализуется вставкой соответствующего присвоения в функцию Loaded.

>Ты даже не представляешь, насколько хорошо и надежно работают в интра-нет приложения, заточенные под интер-нет.

Я представляю насколько они ДОРОЖЕ!!! Я вот, когда говорю заказчику (местному), которому делаю intranet приложение на Delphi, сколько стоит аналогичное интернет приложение на VC, у него лицо меняется и он меня идиотом считает :-) А вот для буржуев - это нормально, имею опыт подобной работы. Состояние экономики+стандарты мышления - страшная сила, делающая Россию unpreferenced заказчиком :-(

>Это уже интересно, клинический случай. Тут уже и на локальной файловой базе не грех приложение сделать. По времени отклика "уделает" любой другой вариант

Ну, моя последняя работа, например, intranet приложение на 1-5 пользователей на MSDE. Ничего плохого в этом не вижу. А вообще бывают ситуации, когда даже на относительно загруженной базе остается, скажем, на 10-15 мин. один пользователь. Вот ему радости-то...
9 ноя 03, 13:33    [410413]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Senin Viktor
Member

Откуда: Подмосковье
Сообщений: 5006
2c127

> На западе я тоже акцесс в качестве клиента не встречал

ЭрнэстЭндЯнг делало для нашей фирмы маленькие проги на Акесе. Да и сама моя фирма не со всем русская :)

>если можно обойтись без всех этих хлопот, если взять нормальный SQL сервер.

Полностью согласен. Сиквел лучше Акеса - как СУБД. Во много раз лучше. Но, есно, для определенных задач. Не будешь же ты ставить сиквел клиенту, которому нужна записна книжка на 1 локальном ПК? Речь в этом топике (если я еще не сбился :) идет о Акесе и Дельфях как Клиентах к некой базе (акесной или сиквельной), причем никто кроме автора не знает, какие требования к системе. М.б. в этой проге 2 человека и будут работать:один до обеда другой после.

==
мы обсуждаем Акес как СУБД или как клиента к СУБД? Я - как клиента. Как СУБД (для работы в сети) Акес с сивелом сравнивать даже не хочу ибо это не сранивается. А как клиента к некой СУБД - можно спорить долго и безрезультатно. Везде полно плюсов и минусов. Да и руки у каждого под разный угол заточены :)
10 ноя 03, 09:30    [410655]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2vdimas:

Честное слово с тобой очень сложно. Тебе говорят что используют один коннект, что ADO и так осуществляет пул соединений, что этот коннект постоянен - а ты про функторы!

Понимаешь - есть различные классы задач - и в каждом из них подходы могут различаться (иногда очень существенно) - так вот для intranet приложений (не придирайся к термину) эффективно использовать именно такую стратегию как постоянный коннект и один поток. И ADO в данном сценарии предоставляет соответсвующие фичи - типа асинхронного режима выполнения запросов (т.е. режима который позволяет не создавая явно еще один поток тем не менее позволять программе работать и не ждать долгих запросов). Так вот для данного класса задач - такой подход эффективен Если твоя задача не принадлежит этому классу - то соответственно и подходы будут другими - но одно другого уж точно не исключает!
Так что в данный момент ты занимаешься флеймом...
10 ноя 03, 10:13    [410695]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
2 Юрий
автор писал:
Честное слово с тобой очень сложно. Тебе говорят что используют один коннект, что ADO и так осуществляет пул соединений, что этот коннект постоянен - а ты про функторы!

Ну, не столько про функторы, сколько про отдельные потоки для инициации серверных операций.

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

Да знаю я все про ассинхронные запросы... :)
Такой подход неэфективен, я уже отвечал Cat2, да ты, видимо, пропустил.

Эфективность - это когда мне не надо озабочиваться какими-то мелочами при проектировании-кодировании приложения. Т.е., долгая операция, строки приходят в грид "постепенно", - пусть его, даже голову не ломаю, перекладываю на дополнительные потоки для работы с данными и все. Да, многие короткие операции вызываю так же из основного потока (около 20%), но это скорее от лени. :)

Простая ситуация:
девочка набивает накладную, скорость - зверская, она "мельтешит" своими пальчиками по гриду, меняет количество в строках. При переходе на следующую строку, текущую это необходимо сохранить в базе, т.к. в моей проге отображаются среди прочих еще остатки с учетом того, что другая такая же девочка именно в этот момент тоже выписывает одноименную позицию. При решении задачи "в лоб", т.е. на событии смены строки - посылаем обновления, работать было невозможно, если одновременно работало ОЧЕНЬ много людей, кто-то вводит документы, кто-то отчеты печатает. Так вот, при интенсивной многопользовательской работе каждая строка сохраняется где-то 0.5-1.5 сек, что ни в какие ворота не лезет, т.к. девочка способна набивать 2-3 строки в секунду (а розничные накладные бывают по 2000 строк - скорость набора крайне важна). Так и что делать? Можно ту же задачу решить ассинхронными вызовами, а можно использовать дополнительный тред. При использовании дополнительного треда (и наличии отлаженного фреймворка :) ), вариант с доп. тредом обходится в 3-4 раза меньшим числом строк кода, да еще практически не нуждается в отладке, т.к. представляет из себя "обычный человеческий алгоритм".
10 ноя 03, 12:03    [410867]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2Дмитрий:

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

Еще - чтоб ты знал VCL - не thread safe - так что я посмотрю как там к тебе в грид будет что-то поступать

P.S> Ты говоришь не о том что эффективно в конкретной ситуации - а о том как это сделать максимально "круто" - и не так как это от тебя ожидают содатели ADO/VCL - хотя я уверен - что ты скажешь что отдельный поток - это просто и очевидно, что у тебя уже написана соответсвующая библиотека, разработа собственная идиома и т.д. Я не против - но буду стоять на том что решение должно быть адекватно задачи ;-)
10 ноя 03, 12:54    [410952]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
Юра писал:
решение должно быть адекватно задачи ;-)

золотые слова!
только, где она - степень адекватности? На что один скажет "а-а-а, и так потянет", другой ответит: "херня получается".

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

тоже самое с данными для гридов на форме и популяции комбобоксов.
User, в общем случае, уже может начинать что-то делать с формой, пока на нее в течении 0.5-3.0 сек не "доковыляют" самые последние данные. :)

VCL - не thread-safe
Покажи мне хоть одну библиотеку, где контролы thread-safe
И, главное, зачем? Любое окно windows создается в неком потоке и только в этом потоке на него приходят события. Thread-safe должен быть объект-источник данных для грида. Если поменяли строку с данными - имеем право вызвать грубый UpdateRect для грида, к нему придет событие WM_PAINT с соотв. параметрами, и тот, уже в своем потоке, отрисует самые последние актуальные данные. Разумеется, напрямую юзать грид не стоит, а вот отнаследовать от него маленький классик - очень даже.
10 ноя 03, 14:19    [411145]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
объекты ADO ( TADOConnection, TADOQuery ) там тоже не thread safe
10 ноя 03, 14:23    [411152]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
все методы роперов этих объектов, кроме тех, которые делают attach, detach (или как там они в дедьфи называются), можешь считать thread-safe, потому как это непосредственно вызов методов COM-объектов из библиотеки ADO.
10 ноя 03, 15:14    [411261]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Pavel
Member

Откуда: Кемерово
Сообщений: 2435
Все все знают про асинхронные запросы в ADO. Только открою вам страшную тайну - ADO не может выполнять более одной асинхронной операции в рамках одного коннекта. Если попытаться запустить 2 паралельных асинхроннных запроса, то ADO создаст второй коннект - копию первого.
10 ноя 03, 19:14    [411684]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
2 Pavel:
Ну, пулинг работает, ну и что ? Как это ухудшает работу приложения ? Улучшает, скорее :-)
10 ноя 03, 19:47    [411707]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
2 Pavel

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

----------
Итак, предлагаю закрыть флейм и подвести итоги:

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

2. В классе приложений, расчитанных на сотни одновременно подключенных клиентов, (независимо от того, в локальной они сети или нет) необходимо выполнять "ритуальные приседания и пляски с бубном", а именно:
- "ручками" контроллировать время жизни коннектов к базе данных, по опыту, было бы неплохо держать коннект открытым 15-60 сек после последнего обращения к базе данных. (никто не мешает задать в настройках приложения этот параметр, равно как и указать, что хоть один коннект обязан быть всегда открытым)
- рассмотреть вариант активного использования ассинхронных запросов или дополнительных рабочих тредов для популяции данными элементов GUI (гриды, листы, комбобоксы и их всевозможные аналоги), а так же для исполнения запросов на изменение данных, либо для запуска всевозможных операций/процедур.
- кеширование (еще не обсуждалось здесь). Необходима развитая система кеширования всевозможного справочного материала, для уменьшения трафика к базе. Если у кого есть интерес, этот пункт можно рассмотреть более подробно.

3. Если используем дополнительные треды для работы с данными, то гораздо эффективней хранить по-одному коннекту на каждый тред, т.е. даже если некий коннект в неком треде и закрыт, то удалять его не следует. (вследствие аппартмент-модели ADO, неэффективно использовать один общий коннект из разных тредов). Учитывая, что при открытии коннекта в соседнем треде не всегда происходит именно создание нового коннекта, а зачастую OLEDB-коннект берется из пула, такая схема представляется наиболее эфективной в случае многопоточной организации способа работы с данными.

4. В случае одиночных "долгоиграющих" запросов вполне подходит асинхронный режим запуска запросов. В случае довольно "ветвистой" логики по исполнению цепочки таких долгоиграющих запросов стоит подумать об организации фреймворка, упрощающего передачу асинхронных задач на исполнение в рабочие треды.
10 ноя 03, 21:44    [411788]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2 Дмитрий

все методы роперов этих объектов, кроме тех, которые делают attach, detach (или как там они в дедьфи называются), можешь считать thread-safe, потому как это непосредственно вызов методов COM-объектов из библиотеки ADO.

К сожалению это не так (во всяком случае у меня в свое время не получилось) - вероятно та часть этих враперов, которая отвечает за связь с Data Aware компоненами вызывала что-то типа dead lock'а


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

кеширование (еще не обсуждалось здесь). Необходима развитая система кеширования всевозможного справочного материала, для уменьшения трафика к базе. Если у кого есть интерес, этот пункт можно рассмотреть более подробно.
Я бы тоже пообсуждал - вот что мне интересно
Опыт применения application servers (EAServer,MTS)
Опыт использования VFP для написания компонетов для app servers - ведь для задач кеширования движок VFP кажется очень привлекательным
Сценарии кеширования ресурсов (не только данных или соединений с БД)
11 ноя 03, 09:49    [412070]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Так, давненько я сюда не заглядывал.

2 vdimas

автор писал:
:) ты вообще хоть иногда в доки заглядываешь?

Disconnect Your Client Cursor from the Connection for R/O and Long-Use Scenarios
Disconnected Recordset objects are supported by the client cursor engine. Use this feature when you are performing a time-consuming operation that doesn't require expensive database resources to be held open. If you need to, you can later reconnect the Recordset to the connection to perform updates.


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

автор писал:
насколько я понял, вы обращаетесь к базе из того же треда, в котором у вас работает основное GUI??? Да еще держите ПОСТОЯННО один глобальный конекшн открытым? Тогда все вопросы к вам немедленно снимаются, извините, конечно, но мы разговариваем на разных языках :)


Да, а что здесь не так. И почему это мы разговариваем на разных языках.


автор писал:
Блин, ну меня умиляет это все У МЕНЯ ЕСТЬ ПОСТОЯННО ПОДКЛЮЧЕННЫЙ ОДИН КОННЕКТ, СМОТРИТЕ КАК Я КРУТ. мдя-я-я...


Ну если это ты так понял, то это твои проблемы.

автор писал:
а при долгих запросах у нас приложение-то замирает и даже не прорисовывается...


Эт почему еще. ProcessMessage еще никто не отменял. И что значит долгие запросы. Может просто не надо таки запросы писать или уметь их оптимизировать.

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


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


автор писал:
Видел такого, написанного именно на дельфи, вот так в лоб, предостаточно. Блин, один глобальный постоянно подключенный коннекшн. Ты еще в книгу это включи, для оболванивания населения.


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

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


Представить очень легко, если знать, какие ресурсы сервера занимает одно открытое соединение. 64 Кб, если не ошибаюс. И что, это что по твоему нагрузка для сервера.

автор писал:
Насчет задержек во время постоянных процедур подключения/отключения. Экспериментально установлено, что если с некоторой базой (именно базой внути инстанса сервака) работает только ОДИН пользователь, то после отключения на некоторое продолжительное время (точно не замерял, что-то около минуты-две), повторное соединие происходит с задержкой (2-3 сек).
Если же с ЭТОЙ базой работает одновременно несколько пользователей, то повторные подключения выполняются мгновенно, по крайней мере, субъективно не заметны оператору.


Ну так работает именно тот самый пуллинг.

автор писал:
Оператор может заполнять один документ произвольное количество времени, и к чему все это время держать конект активным?


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

автор писал:
В 1999-м к моему SQL 7.0-серваку на Celeron-333 256M подключались сотни клиентов и спокойно работали. Кстати, вначале я тоже держал один коннект постоянно открытым. Пока работают десяток-другой клиентов - это не заметно. Но когда больше...


Атлично работает и больше...

автор писал:
Вдогонку, насчет Access. Как раз-таки Access предоставляет пользователю ОДИН ГЛОБАЛЬНЫЙ объект, совместимый по интерфейс с ADODB.Connection, но он заточен спецами по MS SQL таким образом, что клиентское приложение "щадит" ресурсы сервера.


Какой объект, что значит совместимый по интерфейсу. Что у него заточено, что щадит. Давайка вместо чтения рекламного проспекта конкретно с цифирьками.

автор писал:
Но конечно, все это полная чушь, пришел Тигра (pkarklin) и показал разработчикам MS SQL как правильно писать клиентские приложения для ИХ SQL Server.
Научи их, Тигра, научи... а то несчастные разработали MS SQL и сами не поняли, чего там они разработали.


А ты что, думал там боги сидят.

автор писал:
А если стоит задача сократить отрезок времени до ОКОНЧАНИЯ всего проекта, и совершенно фиолетово, когда появится ПЕРВАЯ форма? Понимаешь, от дельфийских компонент заколебешься наследоваться. Т.е. довольно трудоемко компонент писать (относительно простого наследования ради переопределения, скажем, какой-нить мелочи). А я могу наследоваться легко и непринужденно буквально за каждой мелочью. Могу вообще все основные операции в базовые классы запрятать (напр. по работе с сервером). 90% приложения работает само по себе и управляется метаданными. Ручками только всякие drag&drop-ы и прочие неординарности. Для довольно сильного изменения поведения в некотором моменте, встречающемся во всем приложении достаточно "подкрутить" только в одном месте. "Управляемость кода". Слышал такое понятие? Оно напрочь отсутствует там, где формы "рисуются" мышкой, потому как чтобы сделать такую мелочь, как поменять цвет фона или шрифт у всех меток, необходимо прошерстить все 300 и более форм, присутствующие в приложении. :)


Ну вот, теперь ты нам прописные истины втираешь, как надо проекты делать, используя возможности ООП.


автор писал:
девочка набивает накладную, скорость - зверская, она "мельтешит" своими пальчиками по гриду, меняет количество в строках. При переходе на следующую строку, текущую это необходимо сохранить в базе, т.к. в моей проге отображаются среди прочих еще остатки с учетом того, что другая такая же девочка именно в этот момент тоже выписывает одноименную позицию. При решении задачи "в лоб", т.е. на событии смены строки - посылаем обновления, работать было невозможно, если одновременно работало ОЧЕНЬ много людей, кто-то вводит документы, кто-то отчеты печатает. Так вот, при интенсивной многопользовательской работе каждая строка сохраняется где-то 0.5-1.5 сек, что ни в какие ворота не лезет, т.к. девочка способна набивать 2-3 строки в секунду (а розничные накладные бывают по 2000 строк - скорость набора крайне важна). Так и что делать? Можно ту же задачу решить ассинхронными вызовами, а можно использовать дополнительный тред. При использовании дополнительного треда (и наличии отлаженного фреймворка :) ), вариант с доп. тредом обходится в 3-4 раза меньшим числом строк кода, да еще практически не нуждается в отладке, т.к. представляет из себя "обычный человеческий алгоритм".


Это что ж за система, что запись сохраняется 1.5 секунды. А уж про то, что надо разносить формирование отчетов и OLTP, тут даже и говорить нечего. И объясни мне пожалуйста, почему ты решил, что основные тормаза те самые секунды вносит именно последовательная обработка запросов клиентом. Может все-таки с сервреной частью что-то не в порядке.

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


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


Ну что ж давай пообсуждаем. А зачем мне кэшировать 100 000 записей справочника продукции. Ты представляешь, что это будет стоит клиенту. И эта популяция всяких гридов, комбобоксов. Она что, медленно идет, что ты их по тредам распихиваешь? Какие объемы записей там у тебя. Почему ты за трафик то так переживаешь?
11 ноя 03, 17:18    [413280]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
2 praklin

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

автор писал:
Представить очень легко, если знать, какие ресурсы сервера занимает одно открытое соединение. 64 Кб, если не ошибаюс. И что, это что по твоему нагрузка для сервера.

плюс к этому считаем память на каждый открытый рекордсет (гриды на формах) и умножаем это на количество открытых форм (к середине рабочего дня у каждой девочки может быть открыто их около 20-ти, ну не любят они формы закрывать) и умножаем на сотни клиентов
т.е. + (64k (конект) + 24k*2 (среднее кол-во гридов на форме) * 20(форм) ) * 600(клиентов) = > 0.5 Gb только на служебную инфу
а памяти всего 256M (было поначалу, потом 512)

автор писал:
А тысяча-другая записей влетают за доли секнды.
...
Это что ж за система, что запись сохраняется 1.5 секунды. А уж про то, что надо разносить формирование отчетов и OLTP, тут даже и говорить нечего. И объясни мне пожалуйста, почему ты решил, что основные тормаза те самые секунды вносит именно последовательная обработка запросов клиентом.

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

автор писал:
А если вставка записей занимает стока времени, то надо в первую очередь серверную часть смотреть и как с ней работаешь.

уже ответил выше, голая вставка одновременно работающих десятков чел не занимает ничего. мою систему мне заказали на тот момент потому, что вариант 1С на SQL перепроводил большую накладную (300-1000 строк) за минуты (1-5), а больше 30-ти клиентов вообще работать толком не могли. В моей системе перепроводка выполняется за секунды (1-10 в зависимости от нагруженности сервака, в среднем 2-4 сек), а когда работает только 1 клиент, то вообще глазу ничего не заметно (повторяюсь)

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

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

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

автор писал:
Почему ты за трафик то так переживаешь?

тогда это была сетка поделенная на сегменты, большинство из них - на 10Mb, (серверный - на 100Mb) да и небыстрая (по нынешним временам) конфигурация сервера отрицательно относилась к большому трафику.

Вполне сносно работал со своей системой через Dial-UP, и несколько рабочих мест впоследствии работали именно так.

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

----
мою ту старую систему они заменили только этим летом на 1C (в то время как многие фирмы за это же время успели обновить и софт и хард дважды) и взяли под это дело СУМАШЕДШУЮ конфигурацию сервака, и сетку переразвели. На момент замены моя старушка пыхтела весьма весело на P-III 1GHz, 512Mb. Почему я им не стал делать апгрейд? не сошлись по финансовым соображениям. Когда-то им это дасталось за чуть более $600. Москве этого не понять, но в 1999-м зп $250 считалась неплохой для программиста в Севастополе да и сейчас не больно-то выросло, около $400 в среднем, вот и разъезжаются все оттуда :(( .
Сечас дописывать им модули ни за $600 ни за $3600 я не стал. :) Они решили, что 1С им обойдется дешевле. По моим прикидкам, для достижения того же функционала, что был в моей системе им потребуется выкинуть не меньше 20-ки дополнительно помимо покупки самой 1C :) (по Севастопольским ценам, разумеется. Боюсь предположить, сколько это стоит в Москве)
хотя, у меня было гораздо меньше общее число операций. Но вот те, что реально использовались - "заточены" именно под процесс заказчика
11 ноя 03, 21:29    [413642]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
2 vdimas

автор писал:
плюс к этому считаем память на каждый открытый рекордсет (гриды на формах) и умножаем это на количество открытых форм (к середине рабочего дня у каждой девочки может быть открыто их около 20-ти, ну не любят они формы закрывать) и умножаем на сотни клиентов
т.е. + (64k (конект) + 24k*2 (среднее кол-во гридов на форме) * 20(форм) ) * 600(клиентов) = > 0.5 Gb только на служебную инфу
а памяти всего 256M (было поначалу, потом 512)


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

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


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

автор писал:
уже ответил выше, голая вставка одновременно работающих десятков чел не занимает ничего. мою систему мне заказали на тот момент потому, что вариант 1С на SQL перепроводил большую накладную (300-1000 строк) за минуты (1-5), а больше 30-ти клиентов вообще работать толком не могли. В моей системе перепроводка выполняется за секунды (1-10 в зависимости от нагруженности сервака, в среднем 2-4 сек), а когда работает только 1 клиент, то вообще глазу ничего не заметно (повторяюсь)


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


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


Да уж теперь до меня доходит, раз у тебя что на клиенте, что на серваке конфигурации одинаковые - значит сиквел мы используем как хранилише таблиц. Иначе бы (достаточно мощный сервер, по современным ценам $10K за noname сборку) не было такой необходимости в танцах с бубнами над клиентским приложением. И раз по твоим словам производительность системы сильно отличается в зависимости от числа работающих пользователей (прям как в 1с), значит так оно и есть.

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


Сейчас на складах у нас досих пор трудятся 100 пни с 16 метрами памяти. Представляю, если б я в своей задачи кэшировал справочники продукции (около 100 000 записей) и контрагентов (около 20 000 записей) на клиенте. А решается все с помошью форм выбора из справочника по образцу. В ответ на критерии отбора пользователей на сервере вызывается соответствующая хп, которая и возвращает ограниченный набор данных.

автор писал:
тогда это была сетка поделенная на сегменты, большинство из них - на 10Mb, (серверный - на 100Mb) да и небыстрая (по нынешним временам) конфигурация сервера отрицательно относилась к большому трафику.


О каком трафике вааще можно говорить в правильно спроектированной архитектуре клиент/сервер. У нас 100 тока от сервера до первого свича, дальше 10, через мост вааще аркнет (если помнишь на 2,5). А часть клиентов вообще работает через VIP канал шириной 128к. И клиентов (всего) уже давно ни одна сотня. Средняя загрузка 100 на сервере 3%. А у тебя откудато большой трафик нарисовался. Опять это меня заставляет сделать вывод, что система то построена ой как не оптимально.

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


Я и не пытась спорить, а пытаюсь высказать свои мысли. :-)

Дальнейшие заявления на счет замены твоей системы на 1с не буду цитировать. Потому что для меня было бы это крахом. Как мое детише, да на какуюто 1с. Да щас моих юзеров, включая высокое руководство и под дулом пистолета не загонишь на 1с. Значит все-таки система то так себе (без обид тока.)

Вот такие вот, они, мои мысли. А, теперь о выводах. Основной, да и единственный главный, пожалуй. Нельзя рассуждать о способах организации клиентских приложений в отрыве от серверной части системы. Причем имеено гармотное проектировани и разработка последней отнимает гараздо больше времени. Зато результат будет гараздо ощутимей, чем геморой с мультитридом в клиентской части. Моя система охватывает практически все сферы деятельности крупного машиностроительного предприятия, и нигде, повторяю, нигде, мне не понадобилось ассинхронка. Причем не потому, что я этого не умею, а просто не вижу, в решении каких задач она бы мне помогла. Все серъезные аналитические отчеты давно вынесены из OLTP системы и варяться на отдельном серваке (OLAP). Именно принцип разделения OLTP и OLAP систем позволяет решать задачи построения отчетов без нагрузки на операционную часть. А объемы анализируються не малые (несколько лет). А те данные, которые нужны для работы операционной части (ну теже скалдские остатки) доступны в любой момент в предрасчитаном виде, так что никаких проблем ни с трафиком, ни с задержками на выполение запросов не возникает. Если есть желание еще обсудить детали, то можно продолжить. Хотя все равно каждый останется при своем мнении, IMHO.
12 ноя 03, 08:20    [413833]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Давно не заходил сюда. Почитал vdimasa. Извиняюсь, но много смеялся.
Особенно вот над этим:
автор писал:
плюс к этому считаем память на каждый открытый рекордсет (гриды на формах) и умножаем это на количество открытых форм (к середине рабочего дня у каждой девочки может быть открыто их около 20-ти, ну не любят они формы закрывать) и умножаем на сотни клиентов
т.е. + (64k (конект) + 24k*2 (среднее кол-во гридов на форме) * 20(форм) ) * 600(клиентов) = > 0.5 Gb только на служебную инфу
а памяти всего 256M (было поначалу, потом 512)


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

Неплохо бы подучить основы кс и о том, для чего sql сервер придуман. А то действительно получается - на сервер денег тратить не хотим, делать на нем нормально не умеем, поэтому лучше поставим всем клиентов Р4 и будем обрабатывать там.

Эххххх....
Я тоже раньше писал как попало. Но вот повезло - научился.

-- Tygra's --
12 ноя 03, 13:15    [414381]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
aag
Member

Откуда: Москва
Сообщений: 1955
Вдогонку хотелось бы заметить

1) Закрытие-открытие коннекта отнимает время на клиенте. Причем установление соединения занимает относительно большое время, особенно при плохой сетке. Экономя на памяти сервера за счет закрытия неиспользуемого (свободного) соединения, теряем скорость работы клиента. Отдельно хочется отметить, что даже практически любой MSSQL сервер легко держит две-три сотни коннектов. Другое дело - активные коннекты, их должно быть как можно меньше. Но это задача именно серверной оптимизации.

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


Nobody faults but mine... (LZ)
12 ноя 03, 16:36    [415021]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Crip
Member

Откуда:
Сообщений: 2490
2pkarklin
Все то у вас хорошо и красиво, только вот если часты проводки задним числом, причем это число действительно очень заднее тормоза получишь в любом случае как бы ты не разделял OLTP и OLAP...
12 ноя 03, 17:40    [415184]     Ответить | Цитировать Сообщить модератору
 Re: Access or Delphi  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
Между прочим, многое из того, что vdimas говорит, очень актуально в интернет-приложениях (я с ними вплотную сталкивался и думал, что у него подобная практика).
12 ноя 03, 17:56    [415219]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить