Clarion на Хабре

[finsoftrz]

для sql предпочтительнее файловый метод

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

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

[finsoftrz]

У первасива в плане sql была проблема, что он поддерживает две схемы работы, по записям (транзакционную или isam) и выборкам (реляционную или sql). Видимо, не получалось так же эффективно создавать динамические индексы и кешировать запросы.
В этом плане были как раз подвижки в последних версиях actian zen (первасив после ребрендинга). Сделали возможность работать по записям в первичной базе данных, а строить всякие отчёты только через sql запросы во вторичной базе. Базы эти автоматически синхронизируются. Вот это решение было бы интересно сравнить по скорости с другими sql серверами. В actian zen греет то, что размер таблицы расширен до 64 терабайт. Через обычный интерфейс isam к таким объёмам доступа нет, используются дополнительные команды. Но типа с точки зрения обратной совместимости решений можно для всех таблиц использовать обычный доступ, а только для огромных отдельные команды.
Я, кстати, делал класс для прямой работы с actian zen из клариона (без драйвера), позволяющий задействовать расширенные команды чтения, поддерживающие пакетное чтение (заданное количество записей за раз), чтение только заданных полей, а не записей целиком), фильтрацию записей на стороне сервера. Это в isam все. По тестам, на больших объёмах баз можно получить прирост до 10 раз по сравнению с работой через драйвер. На практике пока не пригодилось.

[beneton]

Честно говоря если использовать SQL в связке с шаблоном UltimateSQL, где есть генератор очередей для результатов запросов а также не надо описывать все получаемые в запросе поля. Получается вполне эффективно. Ниже пример:
Вот очередь:

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

qtovar              queue,pre(qtovar)
K_TOVAR            LIKE(tov:K_TOVAR),NAME('K_TOVAR')
N_TOVAR            LIKE(tov:N_TOVAR),NAME('N_TOVAR')
Description        LIKE(tov:Description),NAME('Description')
Artikul            LIKE(tov:Artikul),NAME('Artikul')
K_GRUPPA           LIKE(tov:K_GRUPPA),NAME('K_GRUPPA')
K_COUNTRY          LIKE(tov:K_COUNTRY),NAME('K_COUNTRY')
END

А вот запрос:

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

sql.Query('*select k_tovar, n_tovar, description, artikul, k_gruppa, k_country from tovar where k_tovar in (' & local_k_tovar & ')', qtovar) 

сформированный запрос сразу попадает в дебагер в конечном виде, тут же сразу ставим ловушку очереди:

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

dbg.DebugQueue(qtovar)

Также шаблон позволяет вернуть единичное значение или просто выполнить запрос и вернуть код ошибки если она возникла Например count, сколько надо строчек на кларе чтобы написать подобную конструкцию:

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

sql.query(*select count(id) from tovar where k_tovar in (' & local_k_tovar & ')', tovar_count)

Лично мне sql упрощает выборки из связанных таблиц, использование join и union и прочих прикладных функций, особенно с учетом что у меня в бд нет ни одной связи.
Также мне удобнее и сподручнее отлаживать SQL запрос с учетом что есть еще удобный дебагер UltimateDebug который сразу показывает очередь, вернувшуюся из запроса и позволяет в рантайме выкидывать различные сообщения на экран без использования message.
По совокупности факторов могу сказать что SQL вполне хорошо заходит в паре с UltimateSQL и UltimateDebug

[gopstop2007]

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

Все это есть в - LoadQueueFromSQL viewtopic.php?p=27798#p27798 и не нужен шаблон.