Страница 2 из 10
Btrieve и clarion
Добавлено: 28 Январь 2019, 19:06
Игорь Столяров
Дать пример скрипта на создание DDF P.SQL для таблицы ?
Btrieve и clarion
Добавлено: 28 Январь 2019, 19:28
finsoftrz
SQL, конечно, штука крутая. Но, нет, спасибо, не надо.
Btrieve и clarion
Добавлено: 28 Январь 2019, 19:35
finsoftrz
Про алгоритм рассказывать долго и не нужно это. Считайте, что обычный set по ключу, в котором первое поле дата (long) и оно в заданном диапазоне. Типа такого:
clear(pre:record,-1)
pre:date=dateBeg
set(keyDate,keyDate)
loop
next(file)
if error() or pre:date>dateEbd
break
.
....
.
Вот эта конструкция работает медленно, пока записи после первого прохода не попадут в кэш. Затем быстро. Таблица в районе 8 млн записей, но мы их не все смотрим. Еще в цикле разные get на другие таблицы по первичному ключу, но это мелочь. Вся работа локальная.
Btrieve и clarion
Добавлено: 28 Январь 2019, 19:40
finsoftrz
Не знаю, насколько критично, на том же компе в боевом режиме крутится та же база на tps с реальными пользователями. Висят 12 пользователей в терминальных сессиях и периодически могут еще кто-то коннектиться через ip драйвер. Но и на своем компе ощутимую разницу с скоростях я тоже вижу.
Для tps тоже такой эффект присутствует. Но в меньшей степени.
Btrieve и clarion
Добавлено: 28 Январь 2019, 19:46
Игорь Столяров
finsoftrz писал(а): ↑28 Январь 2019, 19:35Про алгоритм рассказывать долго
Тоже это подозревал, но всё-таки решил спросить …
При выборке по ключу, скорость зависит ещё и от размера самого ключа. Если там несколько полей, среди которых STRING и REAL -
то всё это может заметно тупить, пока ключ не будет загружен в кеш. Также есть смысл прогнать большую БД через REBULD, не зря
ведь в современных версиях добавили фоновую дефрагментацию БД ...
Btrieve и clarion
Добавлено: 28 Январь 2019, 19:57
Игорь Столяров
Не совсем верно сказал … REBULD перестроит и оптимизирует только ключи.
Для дефрагментации самого списка, нужно перезагрузить его через текст при помощи утилиты BUTIL.
Btrieve и clarion
Добавлено: 28 Январь 2019, 20:24
finsoftrz
Нет, в ключах только два long. При обычном чтении set/next тоже заметно. Прерываем процесс. Запускаем заново. До того момента, где прервали бежит быстро, затем опять медленно.
Btrieve и clarion
Добавлено: 28 Январь 2019, 20:41
Игорь Столяров
finsoftrz писал(а): ↑28 Январь 2019, 20:24При обычном чтении set/next тоже заметно.
Попробуйте:
- открыть список только на чтение и как вариант, ещё с монопольным доступом.
- Открыть файл под транзакцией Logout(), т.к. Btrieve не поддерживает LOCK().
Btrieve и clarion
Добавлено: 28 Январь 2019, 21:21
finsoftrz
Я думаю, что разница на порядок связана все таки с тем, что тест проводился на боевом "сервере". По монитору ресурсов, у него вся оперативная память была забита (8ГБ). Кроме учетной системы и терминальных сессий еще запускали openOffice.
Подрихтовал немного процедуру прогрева кэша. На моем компьютере разница до прогрева и после, конечно, заметна, но уже не на порядок. Если еще чего найду, напишу.
Btrieve и clarion
Добавлено: 28 Январь 2019, 22:38
RaFaeL
Игорь Столяров писал(а): ↑28 Январь 2019, 18:11Как ему её посмотреть хотя бы ? Как установить SQL или настроить ODBC источники - Вы ему никогда не сможете объяснить.
Ну во-первых, давайте не мешать в кучу "коробочное решение" и "демо-версию". К коробочному решению прилагается пошаговая инструкция в картинках со всеми нужными ссылками. Если ставить по этой инструкции, то в 95% случаев все работает "из коробки" и не надо ничего настраивать. Просто у вас нет такой инструкции с картинками )) А демо-версию вполне можно собирать на tps, не обязательно полнофункциональную - то, что работает на стороне сервера, мы просто в неё не включаем, это будут "ограничения демо-версии"
Btrieve и clarion
Добавлено: 28 Январь 2019, 23:04
kreator
Игорь Столяров писал(а): ↑28 Январь 2019, 13:46Переход на SQL всё-таки требует переделки всего приложения,
чего избалованные шаблонами программисты Clarion - не любят.
Народ, прекратите! Всех неофитов тут распугаете. Для перехода на SQL нужно только драйвер в словаре сменить. Классы и шаблоны работают с SQL хорошо. Нужно только политику загрузки броуза сменить с Page на File. Очень рекомендуется. Далее можно двигаться в направлении всяких расчётов, отчётов. Менять парадигму set/get на select, хотя и так работает. Многие переходили, и я в том числе. Проблем особых не было, а скорость и все остальные плюхи на лицо.
Btrieve и clarion
Добавлено: 28 Январь 2019, 23:18
RaFaeL
kreator писал(а): ↑28 Январь 2019, 23:04Нужно только политику загрузки броуза сменить с Page на File. Очень рекомендуется.
Ни к чему, просто нужно сделать все ключи, по которым строится броуз, уникальными, а постраничную загрузку отключать не надо
Btrieve и clarion
Добавлено: 29 Январь 2019, 4:22
morkovin
RaFaeL писал(а): ↑28 Январь 2019, 23:18просто нужно сделать все ключи, по которым строится броуз, уникальными, а постраничную загрузку отключать не надо
+ поля, которых нет в броусе, но используются в процедуре, надо обязательно указывать в HotFields
Btrieve и clarion
Добавлено: 29 Январь 2019, 8:18
Игорь Столяров
RaFaeL писал(а): ↑28 Январь 2019, 22:38 Если ставить по этой инструкции
Где-то здесь уже можно подводить промежуточный итог дебатов … Если нет возражений - то я это сделаю.
1. Просто перевести приложение на SQL заменой словаря в общем случае нельзя, нужно вносить изменения в структуру БД
и само приложение. Для Btrieve - можно, в частном случае, можно даже заменить драйвер TPS на Btrieve программно.
2. Просто установить приложение SQL приложение на компьютер нельзя, но можно выполнить некую инструкцию с картинками.
При этом мы должны рассчитывать, на то, что у пользователя есть желание, квалификация и административные права для
её выполнения. Для Btrieve - можно, в частном случае, не требуется отдельно содержать приложение с TPS для "посмотреть".
3. Локальное приложение с SQL будет работать медленнее, чем аналогичное с TPS. А приложение с Btrieve - быстрее, чем с TPS.
При этом, безусловно, у SQL - масса преимуществ, которых нет в ISAM драйверах БД. Это понятно и бесспорно.
Но если говорить, о том, что бы быстро "улучшить" работу существующего приложения с TPS - то драйвер Btrieve безальтернативен.
Как-то оно так получается …
Btrieve и clarion
Добавлено: 29 Январь 2019, 9:28
finsoftrz
Игорь Столяров писал(а): ↑29 Январь 2019, 8:18
При этом, безусловно, у SQL - масса преимуществ, которых нет в ISAM драйверах БД. Это понятно и бесспорно.
Я бы еще добавил то, что у isam тоже есть масса преимуществ, которых нет в sql. Это тоже понятно и бесспорно. Просто две разные технологии, два разных мира. Надо работать в соответствии с выбранной архитектурой и все будет хорошо. Выбор зависит от личных предпочтений, особенностей мышления разработчика, имеющихся наработок и опыта. По какой схеме осуществляется доступ к данным здесь вторично.