Здравствуйте kig, Вы писали:
kig>Да... наверно сумбурно все с самого начала объяснял. kig>Да dataset был еще в 1.0. Вот только в 3.0 они оторвали его от BDE, чем облегчили жисть не только себе, но и нам А адошный, кажется с 5.
Я не знаю как в Дельфит, я про адо говорил. Там он появился далеко не с первой версии, а когда появился то был ну очень негибким.
AVK>>Прозрачно для клиента. kig>Ну вот теперь я думаю, в морде лица клиента можно будет дергание за Борланда заменить на дергание за WebService через SOAP toolkit.
А Борланд умеет веб сервисы?
kig>Ессно с поправкой на stateless (хотя мы сразу особенно на statefull на клиенте не цеплялись, ну кроме того, что коннект тсп-ишный был постоянный).
Ну вебсервисы тоже можно сделать stateful.
T>>Также в удобстве работы. T>>Так например зачем пользователю при воде элемента справочника знать его ID. AVK>А вот тут совсем не понял — пользователь то тут при чем? Скорее пользователю наоборот удобнее, поскольку зная заранее размер выборки можно сделать скроллеры отражающие реальное положение вещей. А зачем ему знать id я честно говоря не понял.
Не понял первое предложение.
Ну допустим есть документ в котором нужно ввести клиента и соответствуещего справочника. Я так понимаю это можно сделать или введя код клиента (ID) или выбрать из списка но для этого нужно чтобы база клиентов была загружена в Датасет. Можно конечно использовать использовать иерархию но когда пользователь незнает в какой группе находится контрагент то придется грузить все записи.
Или это еще как — то можно реализовать?
Например загрузка этого справочника на моей машине занимает до 7 с. А есть и другие.
T>>А грузить его в память не совсем хочется так как он не один и может иметь большой размер. T>>Загружать данные только при необходимости сильно замедлит работу. AVK>Видишь ли какое дело — все равно, если ты не используешь сервернеые курсоры то выборку надо держать на локальной машине. Так что ado.net ничего тут не меняет. Ну а если память жалко — тогда скидывай из datareader не в dataset а на диск, и подгружай по мере необходимости.
Та нет памяти мне вобще не жалко. Только при обращении к справочнику нужно каждый раз его грузить, а это время. А если таких справочников на форме 10 — 20 в среднем загрузка одного справочника 3-5 сек. Пользователь только то и будет делать что ждать загрузки очередного справочника. А если справочники загружать в датасет при открытии то там будет немножко устаревшая информация. Я понимаю что она допустим не так часто меняется но все же.
T>>Использовать иерхическую структуру справочников тоже не всегда получается. AVK>Тем не менее практика показывает что можно обойтись без загрузки огромных массивов данных на клиента. Причина проста — ни один человек все равно не в состоянии воспринять за один раз больше 2-3 килобайт информации. Большие выборки нужны только для автоматической обработки (подготовка отчетов, проводки). А это можно и нужно делать на сервере приложений.
Ну тогда ка сделать выбор по типу 1С (если вы знакомы с этим продуктом)
T>>Также в удобстве работы. T>>Так например зачем пользователю при воде элемента справочника знать его ID. AVK>А вот тут совсем не понял — пользователь то тут при чем? Скорее пользователю наоборот удобнее, поскольку зная заранее размер выборки можно сделать скроллеры отражающие реальное положение вещей. А зачем ему знать id я честно говоря не понял.
Не понял первое предложение.
Ну допустим есть документ в котором нужно ввести клиента и соответствуещего справочника. Я так понимаю это можно сделать или введя код клиента (ID) или выбрать из списка но для этого нужно чтобы база клиентов была загружена в Датасет. Можно конечно использовать использовать иерархию но когда пользователь незнает в какой группе находится контрагент то придется грузить все записи.
Или это еще как — то можно реализовать?
Например загрузка этого справочника на моей машине занимает до 7 с. А есть и другие.
T>>А грузить его в память не совсем хочется так как он не один и может иметь большой размер. T>>Загружать данные только при необходимости сильно замедлит работу. AVK>Видишь ли какое дело — все равно, если ты не используешь сервернеые курсоры то выборку надо держать на локальной машине. Так что ado.net ничего тут не меняет. Ну а если память жалко — тогда скидывай из datareader не в dataset а на диск, и подгружай по мере необходимости.
Та нет памяти мне вобще не жалко. Только при обращении к справочнику нужно каждый раз его грузить, а это время. А если таких справочников на форме 10 — 20 в среднем загрузка одного справочника 3-5 сек. Пользователь только то и будет делать что ждать загрузки очередного справочника. А если справочники загружать в датасет при открытии то там будет немножко устаревшая информация. Я понимаю что она допустим не так часто меняется но все же.
T>>Использовать иерхическую структуру справочников тоже не всегда получается. AVK>Тем не менее практика показывает что можно обойтись без загрузки огромных массивов данных на клиента. Причина проста — ни один человек все равно не в состоянии воспринять за один раз больше 2-3 килобайт информации. Большие выборки нужны только для автоматической обработки (подготовка отчетов, проводки). А это можно и нужно делать на сервере приложений.
Ну тогда ка сделать выбор по типу 1С (если вы знакомы с этим продуктом)
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>Да... наверно сумбурно все с самого начала объяснял. kig>>Да dataset был еще в 1.0. Вот только в 3.0 они оторвали его от BDE, чем облегчили жисть не только себе, но и нам А адошный, кажется с 5. AVK>Я не знаю как в Дельфит, я про адо говорил. Там он появился далеко не с первой версии, а когда появился то был ну очень негибким.
Чего-то в адо (я не про дотнет) я про датасеты не слышал. Может ты про стирмы адошные говорил? Тогда в MDAC2.5.
Или о чем другом?
AVK>>>Прозрачно для клиента. kig>>Ну вот теперь я думаю, в морде лица клиента можно будет дергание за Борланда заменить на дергание за WebService через SOAP toolkit. AVK>А Борланд умеет веб сервисы?
В 6 чего то умеет... Но я даже не смотрел. Теперь то зачем, когда дотнет есть. Я теперь хочу дергать за вебсервисы, написанные на дотнете. Как я уже говорил — клиент старый остается (с поправкой на SOAP toolkit) — а сервак уже новый будет. Ну правда не совсем Пока останется старое адо, по крайней мере в той части, которая для клиента предназначена.
kig>>Ессно с поправкой на stateless (хотя мы сразу особенно на statefull на клиенте не цеплялись, ну кроме того, что коннект тсп-ишный был постоянный). AVK>Ну вебсервисы тоже можно сделать stateful.
Ты имеешь в виду сохранение данных между запросами (привязка к сессии и т.п.)?
Здравствуйте Аноним, Вы писали:
А>Здравствуйте AndrewVK, Вы писали:
А>Не понял первое предложение. А>Ну допустим есть документ в котором нужно ввести клиента и соответствуещего справочника. Я так понимаю это можно сделать или введя код клиента (ID) или выбрать из списка но для этого нужно чтобы база клиентов была загружена в Датасет. Можно конечно использовать использовать иерархию но когда пользователь незнает в какой группе находится контрагент то придется грузить все записи.
Да, придется. Причем в любом случае, вне зависимости от используемой технологии. А>Или это еще как — то можно реализовать?
Никак. А>Например загрузка этого справочника на моей машине занимает до 7 с. А есть и другие.
Думать как разбить этот справочник на части.
А>Та нет памяти мне вобще не жалко. Только при обращении к справочнику нужно каждый раз его грузить, а это время. А если таких справочников на форме 10 — 20 в среднем загрузка одного справочника 3-5 сек. Пользователь только то и будет делать что ждать загрузки очередного справочника. А если справочники загружать в датасет при открытии то там будет немножко устаревшая информация. Я понимаю что она допустим не так часто меняется но все же.
Можно завести в специальной таблице запись в которую писать дату последнего изменения справочника и при каждом обращении сверять эту дату с тем что в памяти или на локальном диске. Если отличается то справочник нужно перегрузить. Поскольку справочники изменяют как правило редко то получишь весьма существенный выигрыш в быстродействии.
А>Ну тогда ка сделать выбор по типу 1С (если вы знакомы с этим продуктом)
Не то слово, будь он неладен. Я тебе скажу как это сделано там, а ты уж решай, стоит ли оно того. 1С при обращении к справочнику просто копирует файл справочника с индексами. При каждом обращении сверяет дату модификации локального файла и файла в базе и если в базе файл другой то копирует его по новой. Ну а работает уже с локальной дбфкой. Ну и справочники в 1С все иерархические.
Здравствуйте kig, Вы писали:
kig>>>Ессно с поправкой на stateless (хотя мы сразу особенно на statefull на клиенте не цеплялись, ну кроме того, что коннект тсп-ишный был постоянный). AVK>>Ну вебсервисы тоже можно сделать stateful. kig>Ты имеешь в виду сохранение данных между запросами (привязка к сессии и т.п.)?
Да
Здравствуйте AndrewVK, Вы писали:
AVK>Не то слово, будь он неладен. Я тебе скажу как это сделано там, а ты уж решай, стоит ли оно того. 1С при обращении к справочнику просто копирует файл справочника с индексами. При каждом обращении сверяет дату модификации локального файла и файла в базе и если в базе файл другой то копирует его по новой. Ну а работает уже с локальной дбфкой. Ну и справочники в 1С все иерархические.
А что так сумбурно по поводу 1С? По моему не плохое средство для быстрой разработки экономического и бухгалтерского ПО. Я просто занимаюсь внедрением 1С на средних и малых предприятиях уже более 3 лет. И сомневаюсь что там действительно так реализована работа со справочниками и другими объектами Журналами, Журналами расчетов. А как же в веорсии SQL хотя я знаю 1с использует SQL только как хранилище данных.
И если 1с копирует файлы может ты знаеш где они находятся?.
Здравствуйте Thunder, Вы писали:
T>А что так сумбурно по поводу 1С? По моему не плохое средство для быстрой разработки экономического и бухгалтерского ПО.
Я где то сказал что но плохое?
T> Я просто занимаюсь внедрением 1С на средних и малых предприятиях уже более 3 лет.
Я тоже.
T> И сомневаюсь что там действительно так реализована работа со справочниками и другими объектами Журналами, Журналами расчетов.
Не сомневайся. И посмотри при запущенной 1С в temp-каталог — увидишь там половину базы. Журналов кстати нет — есть один единственый общий журнал, остальные получаются выборками из него.
T> А как же в веорсии SQL хотя я знаю 1с использует SQL только как хранилище данных.
Коли знаешь то чего спрашиваешь? Также копируется в dbf на диск.
T>И если 1с копирует файлы может ты знаеш где они находятся?.
А ты догадайся с трех раз
AVK>Не сомневайся. И посмотри при запущенной 1С в temp-каталог — увидишь там половину базы. Журналов кстати нет — есть один единственый общий журнал, остальные получаются выборками из него.
Весе темпы обшарил но не нашол таблиц ну ладно может они в памяти держатся.
Видел только что создается файл меньше 1К и пустой каталог. Да и место на диске не уменьшается.
Это так может я конечно и не прав. Спасибо за интерестную дискусию.
Может что еще посоветуеш (если я еще не надоел)
И вот как я придумал работать:
1. Заводим дополнительную таблицу
где будет одно поле с именем всех таблиц,
другое с датой последнего обновления.
2. Заводим во всех таблицах 2 дополнительных поля
в первом будет фиксироватся дата и время последнего обновления поля,
во втором дата и время последнего блокирования.
Ну и естествено исходя из этих данных будет ненужно загружать
повторно все данные а только измененные. А их будет совсем немного.
Это все можно навешать на таймер ~1мин (вычеслается пробным путем).
И таким образом будут поддерживатся актуальные данные.
При выходе из программы можно будет скидывать весь датасет на диск
и при следуещем запуске просто считывать данные и обновить устаревшие.
Но это не обязательно.
Еще надо будет подумать как обновлять удаленные данные.
Можно завести еще одну таблицу.
Но при таком раскладе у меня возникает вопрос где брать дату и время обновления? :???:
С машины пользователя некоректно так как оно может сильно отличатся или быть неправельным.
Единственно что я придумал это запустить програмульку на сервере которая будет отдавать время и дату.
Здравствуйте Гром Олег Васильевич, Вы писали:
ГОВ>Весе темпы обшарил но не нашол таблиц ну ладно может они в памяти держатся.
Не там наверное искал. Набери в командной строке set temp.
ГОВ>Видел только что создается файл меньше 1К и пустой каталог. Да и место на диске не уменьшается.
Да нет, там должно быть сотни полторы файлов.
ГОВ>Это так может я конечно и не прав. Спасибо за интерестную дискусию. ГОВ>Может что еще посоветуеш (если я еще не надоел) ГОВ>И вот как я придумал работать: ГОВ>1. Заводим дополнительную таблицу ГОВ>где будет одно поле с именем всех таблиц, ГОВ>другое с датой последнего обновления.
Нормально.
ГОВ>2. Заводим во всех таблицах 2 дополнительных поля ГОВ>в первом будет фиксироватся дата и время последнего обновления поля,
Я думаю это излишне, разве только для очень больших справочников. ГОВ>во втором дата и время последнего блокирования.
А это зачем?
ГОВ>Ну и естествено исходя из этих данных будет ненужно загружать ГОВ>повторно все данные а только измененные. А их будет совсем немного. ГОВ>Это все можно навешать на таймер ~1мин (вычеслается пробным путем).
Зачем? Можно просто при каждом обращении. Если только не обновлять датагрид сам по себе.
ГОВ>При выходе из программы можно будет скидывать весь датасет на диск ГОВ>и при следуещем запуске просто считывать данные и обновить устаревшие. ГОВ>Но это не обязательно.
Да, это тоже наверное излишне. Разве только если программа работает через инет по медленным каналам.
ГОВ>Но при таком раскладе у меня возникает вопрос где брать дату и время обновления?
ГОВ>С машины пользователя некоректно так как оно может сильно отличатся или быть неправельным. ГОВ>Единственно что я придумал это запустить програмульку на сервере которая будет отдавать время и дату.
ГОВ>Может что-то подскажеш. ГОВ>Зарание благодарен.
GetDate() прямо в запросе для Transact SQL. Можно прямо в триггер на добавление.
А адошный, кажется с 5. 
Пока останется старое адо, по крайней мере в той части, которая для клиента предназначена.
