Смена драйвера БД

finsoftrz

Разные есть мнения на этот счет. Там только один нюанс - надо вовремя явно применять round. Плюсы же перечислять - пальцев на руке не хватит

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

George

kreator писал(а): Человек, создавший тему, не говорит необходимость такого решения, поэтому сложно советовать. Может, всё банально. Я в своё время генерил БД в SQLAnywhere из TPS. Тупо в словаре поменял драйвер, и Кларион создал все таблицы сам (не помню, как насчёт форейн-ключей). Поэтому, если бы можно было бы использовать prop:Driver, то прокатило бы в определённых условиях. Проблема как раз в prop:Driver, надо проверять на запись.

Все очень банально. Пробую делать универсальное приложение, которое может работать с разными типами БД (например Topspeed и Firebird) в зависимости от условий.
К сожалению, PROP:Driver не работает.

kreator

George писал(а):Все очень банально. Пробую делать универсальное приложение, которое может работать с разными типами БД (например Topspeed и Firebird) в зависимости от условий.
К сожалению, PROP:Driver не работает.

Сразу бы сказали, мы бы и отсоветовали сразу. К сожалению, работа в SQL и файл-серверных системах кардинально различается. Не стоит даже и думать о скрещивании. Может имеет смысл использовать для всех систем ODBC или ADO. Как раз позиционируются, как универсальные. И ещё момент (поскольку работал с разными SQL серверами). Правильная работа с ними - через прямые SQL-запросы (а также использование хранимок, триггеров). Но синтаксис языка SQL немного у всех отличается, т.е. имеет быть определённая проблема (хотя можно остановится на "классическом" SQL).

George

kreator писал(а): Сразу бы сказали, мы бы и отсоветовали сразу. К сожалению, работа в SQL и файл-серверных системах кардинально различается. Не стоит даже и думать о скрещивании. Может имеет смысл использовать для всех систем ODBC или ADO. Как раз позиционируются, как универсальные. И ещё момент (поскольку работал с разными SQL серверами). Правильная работа с ними - через прямые SQL-запросы (а также использование хранимок, триггеров). Но синтаксис языка SQL немного у всех отличается, т.е. имеет быть определённая проблема (хотя можно остановится на "классическом" SQL).

На простых пробных приложениях не заметил проблем при переводе в словаре с Topspeed на SQL (MSSQL и Firebird).И Browse и Form вроде отрабатывают все корректно.

kreator

George писал(а):На простых пробных приложениях не заметил проблем при переводе в словаре с Topspeed на SQL (MSSQL и Firebird).И Browse и Form вроде отрабатывают все корректно.

Несомненно, драйвера Клариона отрабатывают как надо. По большому счёту обычные броузы не требуют специальной адаптации. Драйвер переводит в SQL запрос. Проблемы начинаются когда нужно, допустим выдать в столбце броуза некую сумму по другой таблице. В случае TopSpeed делаем цикл по ключу и суммируем. В случае SQL такой путь вызовет катастрофическое падение производительности. Допускаю, что при небольших по размеру таблицах всё будет OK, но в общем случае всё очень плохо.
Чтобы понять разницу, можно на относительно большой таблице (5-10 тыс записей) сделать цикл по таблице с next и previous и посмотреть результат. Подозреваю, что любой SQL очень сильно проиграет топспиду.

Shur · Сообщение **Shur** » 18 Февраль 2016, 1:08

Чтобы понять разницу, можно на относительно большой таблице (5-10 тыс записей) сделать цикл по таблице с next и previous и посмотреть результат. Подозреваю, что любой SQL очень сильно проиграет топспиду.

Замерил. MS SQL. Сервер откровенно слабый -- фактически десктоп.
Код следующий:

Код: Выделить всё

message('start',records(changes))
clock# = CLOCK()
setcursor(CURSOR:Wait)
clear(chng:record)
set(changes)
LOOP
   next(changes)
   if errorcode()
      break
   .
.
clock# = CLOCK() - clock#
setcursor()
message('finish: ' & format(clock#,@t4)&'|'&clock#/records(changes)&' 1/100 sec',records(changes))

Результат показывает, что 150603 записи были просканированы за 0:07:57, т.е. на одну запись пришлось по 0,00317 секунды.
Сильно проиграл?

P.S. Запрос в самом SQL отработал за 0:01:08.

Код: Выделить всё

    declare @var int
    declare @i int = 0
    declare cur1 cursor DYNAMIC for
       select id from dbo.db_changes
    open cur1	
    while (0=0) 
    begin
       fetch next from cur1 into @var
       if (@@FETCH_STATUS = -1) begin
 	    break
       end
       set @i += 1
    end
    close cur1	
    deallocate cur1
    print @i

Думаю, сильно, 150 тысяч записей должны выбираться за секунды, а не за 8 минут.

Shur · Сообщение **Shur** » 18 Февраль 2016, 1:39

Должны-то должны. Кто даст конкретный замер по TopSpeed?

Shur · Сообщение **Shur** » 18 Февраль 2016, 2:00

Впрочем замерил сам.
Код тот же. TOPSPEED. Комп тот же, что в первом тесте был сервером.
354303 записей просканировано за 0:00:17. Т.е. на чтение одной записи ушло 0,000048 сек.
Таким образом TOPSPEED в 66 раз быстрее, чем динамические sql-ные курсоры.
Да уж, делайте выводы, как писать под SQL.

P.S. Думал, почему такая большая разница. Пришёл к выводу, что тесты не вполне сопоставимы. Если в случае с SQL была какая-никакая, а клиент-серверная среда с прокачкой по сети (22,82 Мб в одну сторону и 315,25 Мб в другую на 100М сети), то во втором случае было десктоп-приложением с чтением из локального файла.
Так что вопрос остаётся: кто-то может дать качественные сопоставимые замеры для сравнения?

Ал · Сообщение Ал » 18 Февраль 2016, 9:25

самая "веселуха" в переходный период - с dat|tps -> sql, когда все "живет" и крутится круглосуточно - данные постоянно падают в базы старых форматов/пред версий и для перехода одномоментно невозможно "тормознуть" процесс и перевести все\всех разом...

kreator

Shur писал(а):Так что вопрос остаётся: кто-то может дать качественные сопоставимые замеры для сравнения?

Я про то и говорю - set/next в случае SQL не работают. Надо перед loop'ом поставить код типа:

Код: Выделить всё

changes{prop:SQL} = 'select * from changes'

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

Shur

kreator писал(а): Я про то и говорю - set/next в случае SQL не работают.

Креатор, как это не работает? Работает.
И по условию задачи (темы) я сейчас не говорю о какой-либо кастомизации под отдельные типы драйверов.
Кэширование в своём тесте я исключил -- привёл данные первого выполнения. Повторные замеры не дали ускорения. Ещё раз повторюсь -- тормозом могла оказаться сеть сама по себе. Надо было попробовать запустить тест на самом сервере, но это уже только вечером смогу.

kreator

Понимаешь, когда мы делаем Set (по файлу или ключу), а потом Next, то драйвер Клариона преобразует это всё равно в некий Select. Поэтому, сделав 10000 Next'ов мы поимеем 10000 Select'ов. Чтобы этого избежать, используем prop:SQL для отдельной таблицы или для вьюхи. Стандартный броуз работает именно так. Он понимает, что таблица скульная и посылает серваку prop:SQL.

Shur

kreator писал(а): Понимаешь, когда мы делаем Set (по файлу или ключу), а потом Next, то драйвер Клариона преобразует это всё равно в некий Select. Поэтому, сделав 10000 Next'ов мы поимеем 10000 Select'ов. Чтобы этого избежать, используем prop:SQL для отдельной таблицы или для вьюхи. Стандартный броуз работает именно так. Он понимает, что таблица скульная и посылает серваку prop:SQL.

Не знаю, какой именно драйвер ты называешь драйвером Клариона, но драйвер для MS SQL работает совершенно иначе. Он открывает для каждого стандартного броуза динамический курсор в SQL, который, собственно, и позволяет пользователю скроллировать броуз вперёд-назад (не выполняя при этом 10000 селектов).
Неужели на форуме это ещё не обсуждалось, и зачем к этому возвращаться.

kreator

Shur писал(а):Не знаю, какой именно драйвер ты называешь драйвером Клариона, но драйвер для MS SQL работает совершенно иначе. Он открывает для каждого стандартного броуза динамический курсор в SQL, который, собственно, и позволяет пользователю скроллировать броуз вперёд-назад (не выполняя при этом 10000 селектов).
Неужели на форуме это ещё не обсуждалось, и зачем к этому возвращаться.

Ну и что? Драйвер использует курсоры. Что это значит? В хелпе по этому поводу написано только то, что старайтесь по возможности использовать Unique Constraints. А кто знает внутренний механизм драйвера? У меня, к примеру, есть подозрение, что курсор открывается 10000 раз и 10000 раз закрывается.