Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2003.07.17;
Скачать: [xml.tar.bz2];

Вниз

max кол-во колонок в EhDBGrid   Найти похожие ветки 

 
Vick   (2003-06-24 10:06) [0]

Доброго всем утра!!!
Возник такой вопрос: у меня выполняется запрос с динамическим числом выводимых полей, иногда их очень много (до 400). Я понимаю что это аморально, но так просит бухгалтерия. Запрос выполняется отлично, но время вывода его в EhDBGrid из ADO просто фантасктическое - до 10-ти мин (динамические колонки создаются очень быстро, а вот загрузка в них данных... хотелось бы быстрее). Какое max кол-во полей способен нормально обрабатывать EhDBGrid? И может кто другой вариант предложит, буду благодарна. Может я что-то не так делаю???

Заранее спасибо


 
Johnmen   (2003-06-24 10:09) [1]

Интересно, а что бухгалтерия охватывает своим орлиным взором сразу все 400 колонок ? Да и записей, наверно, немеряно ?
:)))


 
Vick   (2003-06-24 10:24) [2]

ООООООО!!! У бухгалтерии фантазия просто шикарная, она хочет видеть по 50-ти магазинам одновременно продажи и остатки на конец дня вместе с суммами по разнм типам цен по всем артикулам - получется по оси Y у меня артикулы по X - все магазины с кол-вами и ценами (артикулов больше 15 тыс.)


 
Zacho   (2003-06-24 10:31) [3]


> Vick © (24.06.03 10:24)

Примерно представь объем такого набора данных, и прикинь сколько времени займет просто передача его по сети с сервера на клиент. Imho, 10 мин - вполне нормально :-)


 
Danilka   (2003-06-24 10:33) [4]

Класс! Давно так не смеялся! :)))


 
Johnmen   (2003-06-24 10:37) [5]

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

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


 
Vick   (2003-06-24 10:52) [6]

>Johnmen ©

Запрос динамический, они могут выбрать магазинов сколько им хочется, так вот на 20-30-ти еще работает отлично, при чем запрос выполняется мин. за 3, остальное уходит на его загрузку в таблицу.


 
Danilka   (2003-06-24 10:56) [7]

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


 
Vick   (2003-06-24 10:59) [8]

> Danilka ©
Это сначала нужно доказать начальнику :)))) А он вот уже вторую неделю не поддается ни на какие уговоры и обоснования


 
Danilka   (2003-06-24 11:01) [9]

Vick © (24.06.03 10:59)
Надо ему распечатать эту таблицу 12-м шрифтом, пусть анализирует. :))


 
Zacho   (2003-06-24 11:07) [10]


> Vick © (24.06.03 10:59)

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


 
Vick   (2003-06-24 11:18) [11]

> Zacho ©

УГУ!!! Это мы с тобой понимаем это, а для него нет ничего невозможного :))))


 
Sandman25   (2003-06-24 11:33) [12]

Vick © (24.06.03 11:18)

Продемонстрируйте начальству и бухгалтерии, что программа нормально работает для 20 магазинов. Если они указывают 40 и программа начинает тормозить, то объясните начальнику, что время работы будет не в 2 раза больше, а гораздо больше из-за начинающихся перегрузок сети, нехватки памяти и т.д.
Пусть тогда запускают 2 отчета по 20 магазинов.


 
Danilka   (2003-06-24 11:40) [13]

Vick © (24.06.03 11:18)
Сомневаюсь, что он не поймет того, что для формирования и передачи по сети 6 миллионов полей (400*15000) необходимо более мощное оборудование.

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

Бумага, она на любого начальника действует, проверено. :))


 
Vick   (2003-06-24 11:46) [14]

Да по сети передается быстро, в таблицу медленно рисуется


 
Danilka   (2003-06-24 11:52) [15]

Vick © (24.06.03 11:46)
Ну, тогда это еще лучше - в докладной надо будет добавить стоимость клиентских машин: самые последние процессоры, памяти под гигабайт. Только про сеть все-таки незабудь написать, если он на самом деле такой идиот, что для него обновить оборудование будет проще, чем сделать по человечьи, то пусть уж и сетку с серваком обновит, непомешает.


 
интересующийся   (2003-06-24 11:55) [16]

>ООООООО!!! У бухгалтерии фантазия просто шикарная, она хочет >видеть по 50-ти магазинам одновременно продажи и остатки на >конец дня вместе с суммами по разнм типам цен по всем >артикулам - получется по оси Y у меня артикулы по X - все >магазины с кол-вами и ценами (артикулов больше 15 тыс.)
А при чем здесь EhDBGrid?
По-моему, это типичный отчет в конце дня,
ну и выдавайте им в виде отчета




 
Danilka   (2003-06-24 11:59) [17]

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


 
Danilka   (2003-06-24 12:00) [18]

интересующийся (24.06.03 11:55)
а зачем?
во времена бумажного учета такой отчет имел смысл, сейчас нет.


 
Интересующийся   (2003-06-24 12:07) [19]

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

Vick
а вообще надо настоять на своем, в этом согласен с Danilka


 
Sandman25   (2003-06-24 12:09) [20]

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


 
интересующийся   (2003-06-24 12:15) [21]

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

Vick
Твой вопрос не решается технически, но административно


 
Семен Сорокин   (2003-06-24 12:19) [22]

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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2003.07.17;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.49 MB
Время: 0.008 c
1-55512
Ш-К
2003-07-04 16:55
2003.07.17
Повторный запуск приложения.


6-55677
Clipper
2003-05-12 02:40
2003.07.17
Raw Soket


14-55794
AlexRush
2003-06-30 20:40
2003.07.17
NtQuerySystemInformation - Как получить PID ?


11-55486
Avenger__
2002-11-09 14:08
2003.07.17
ListView and WinXp


14-55766
MBo
2003-06-28 10:40
2003.07.17
Выбрать стратегию...





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский