Перевожу программы в терминальный режим. Будут ли проблемы?

[kreator]

FinSoft писал(а):
Проблем нет, все очень быстро и надежно, у sql серверов в данных вопросах преимуществ нет.
Смеялся

Я тоже посмеялся. Потом порылся в Интернете. Все отзываются хорошо. Реально ускоряет работу. Вопрос у меня все равно стоит - зачем мы используем SQL сервера? Подозреваю, что есть какие-то подводные камни в терминальном режиме.

[Admin]

NoSQL - новый тренд. Вау. Супер, ток нафиг пока...
Вызвало улыбку "быстро и надежно", после SQL слабо верится в скорость TopSpeed на базах с миллионом или несколькими миллионами записей...
Вот примеров того как все раком встает достаточно было.

Сугубо мое IMHO, никого никуда не тяну.

[AlesDales]

Поработав с SQL (Ms Sql конкретно) технологией могу сказать, что это просто магия для программиста, никакой Topspeed драйвер хоть в терминале хоть в локалке рядом не лежало. Это притом что за Topspeed убить был готов когда-то.

[FinSoft]

Все проблемы были у топспидовских баз при работе в файл-серверном варианте. Думаю, что разработчики в SV (Topspeed) изначально пошли по сомнительному пути, предлагая работать с этим форматом в таком варианте. То, что индексы располагаются в одном физическом файле с данными и выполняется постоянная автокомпрессия, надежности, мягко говоря, не добавляют. Надо уж тогда было сразу предлагать что-то типа ip-драйвера. К примеру, когда разработчиков sqlLite спросили, пробовали ли они работать со своей базой в файл-серверном режиме, те были очень удивлены и ответили, что библиотека в таком режиме не тестировалась (!). У них тоже есть проект, похожий на доступ через наш ip-драйвер.
Как tps живет на терминале с большими базами? Могу по опыту сказать, что в пределах 500 мб и 2-3 миллионов записей без проблем и потери производительности. Мне показалось (субъективно), что более 500мб появилось некоторое замедление. Но, вообще говоря, для обычных приложений ограничений tps вполне хватает, т.к. его таблички занимают места значительно меньше, чем скульные базы. Сравнивал как-то сразу после заливки в MS SQL, была разница примерно в 8 раз, в процессе работы должно еще подрасти. А так нужно считать. У меня получилось, что критичными к размеру всего 2 таблицы - строки товарных документов и архив лога изменений в базе. Последний можно просто переименовывать, когда подходит к 2гб, все равно только на чтение. Для таблицы строк товарных документов я сделал зеркальный архив. Когда подходим к 300-500 мб, переливаем часть данных в него. Отчетная система работает с двумя таблицами (основная и архив), как с одной.
Почему многие работают с sql, а не с терминалом? Мэйнстрим, куча бабла вложена в продвижение. Ну и свои преимущества, конечно, есть (я про них уже писал). Терминальный доступ был давно, но за системы требовали немаленькие по нашим меркам деньги, и компьютеры необходимой мощности стоили немало, было сильное ограничение на количество работающих пользователей (делали фермы из нескольких серверов, что еще более удорожало систему). Это сейчас пишут про сервера с 80 ядрами и кучей гигов озу, как о чем-то обычном. Терминальных решений стало, пожалуй, практически столько-же, сколько скулей, если не больше. Раньше был MS TS, цитрикс, канадский GoGlobal, итальянцы давно свою систему делали (точно не помню название). Сейчас есть даже российская контора, которая предлагает недорогой терминальный доступ.
Плюсы использования tps+терминал вполне очевидны. Очень просто, работаешь с обычной локальной программой. Кроме клариона ничего не надо, все зависит только от нашей фантазии. Вся программа и все, что нужно для ее работы, в одной папке. Никаких конфликтов с другим ПО, никакого гемороя с межпрограммным обменом. Хорошо понимаешь, как работает программа, всегда можешь быстро диагностировать проблему, т.к. 99%, что она в твоем коде.
Я как бы не агитирую отказываться от работы со скулем, но если человек всю жизнь работал со встроенными файловыми базами, то сейчас ему совсем не обязательно идти в клиент-сервер, достаточно просто поднять стандартный терминал. Переписывать программу не надо (только, возможно, подправить работу с локальными временными таблицами и настройками) и все будет работать на 1-2 порядка быстрее, чем в файл-сервере, а про сбои с потерей информации можно забыть, как о страшном сне. Если вдруг выйдем за ограничения tps, то тоже не беда - можно поднять отдельный сервер с первасивом, и опять, не нужно практически ничего менять в программе. Но это уже системы с более чем 50-60 конкурентных пользователей, таких еще поискать надо. Конечно, клиентам должен быть важен прикладной функционал, а не на чем система работает. Закрытость решений на tps никто не отменял. Но в одних случаях закрытость выгодна (тиражные решения как есть), в других нет (заказные решения).

[Shur]

Мне кажется, что _правильно_проиндексированный_ TPS по скорострельности вряд ли уступает SQL, ведь принцип доступа к конечным данным примерно одинаков -- через таблицу индексов.
Верно и то, что для тиражных десктопных решений SQL подходит значительно хуже.
Решение о том, какую СУБД использовать, по-видимому принимается по совокупности факторов: цель, задачи, сроки, стоимость (как самой разработки так и стоимость всего решения). Можно пойти дальше, вспомнив о сопровождении продукта и т.д.
Одно преимущество связки SQL+Кларион я всё же укажу: модификация таблиц происходит практически безболезненно -- вы можете добавить поле на работающей базе, затем обновить версию клиентской программы. Пользователи этого даже не почувствуют на себе.
А вот с TPS как и с остальными ISAM-драйверами (кроме, пожалуй, DOS, ASCII, BASIC) -- проблема, Кларион требует полного совпадения описанного формата. В своё время у меня в тиражной программе был вызов процедуры преобразования форматов -- описываем источник, описываем новый формат, конвертируем, переименовываем. И так от версии к версии, от таблицы к таблице. А программа к тому же была многопользовательская... А как дела обстоят сейчас? Finsoft, поделитесь опытом.

[Губин Игорь]

Мне кажется...

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

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

Теперь, имхо, вопрос выбора терминал/sql стоит только в плоскости идеологии клиентов в сети и идеологии построения самой информационной системы. В остальном (если не брать в расчёт наследуемые решения), они уже практически равнозначны.

Только два НО для терминального доступа:
1. физическое ограничение на количество клиентов в сети. С этой точки зрения у SQL решений лаг больше.
2. SQL позволяет организовать доступ к данным из программ разных разработчиков. Т.е. данные открыты для доступа

Только два НО для SQL
1. SQL не даёт программе работать по принципу "всё своё ношу с собой". Т.е. влияние внешних факторов (настройка сети, установка сторонних программ и т.п.) на работу программы достаточно велико.
2. в вопросе защиты данных от несанкционируемого доступа программа вынуждена практически целиком полагаться на интеллект и профессионализм третьих лиц, что не самым лучшим образом сказывается на секретности

Подчёркиваю, всё это ИМХО.

P.S. А проблема изменения структуры файлов осталась как и была...

[FinSoft]

Я сделал себе пару шаблонов для автоматической конвертации. Первый (утилитный) генерит текстовый файл с декларациями таблиц. Вначале туда записываются все декларации, затем только измененные. Разделяются строкой с номером версии. Второй шаблон (процедурный) генерит рутинки конвертации на основании этого текстового файла, сразу по всем версиям. На выходе получаем специальный небольшой exe-конвертор. При запуске на рабочей базе он пытается открыть таблицы для каждой очередной версии, если без ошибки, то считаем, что это текущая версия. Далее конвертим автоматом до самой последней версии. Пользователей, конечно, приходится выгонять. Зато сама подготовка конвертора занимает секунды и не важно, какая версия базы данных стоит у клиента. Периодически (раз-два в год) файл с декларациями и exe-конвертор переименовываются (на всякий случай) и весь процесс начинается сначала.
Еще есть специальные коммерческие инструменты DC и FM, многие пользуют их.

[Губин Игорь]

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

[FinSoft]

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

[Shur]

FinSoft, то есть у вас с выходом новой версии при изменении формата приходит дополнительный exe-шник, который запускается и конвертирует данные.
А как это может происходить организационно? Информационное письмо с просьбой запустить конвертор? Или как-то ещё?

И насколько проще модификация структур в случае выбора SQL, если нет удалённого доступа?

[morkovin]

И насколько проще модификация структур в случае выбора SQL, если нет удалённого доступа?

Да полная труба. Последнее время сталкиваюсь с тем, что изменения структуры ( SQL2000 + Win2008+AD) никак не проявляются на клиентах до перезапуска SQL-сервера. А вот для этого нужны соответствующие привилегии, которых у меня, например, нет.

[optron]

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

Ну дык на терминальный режим перейти быстрее и безболезненней. Переписывать особо ничего не нужно. А с SQL... Пару лет назад пробовал через ОДБС поработать с MySql в Клаше 5,5. Работает, но лично у меня почему - то проблема следующего рода возникала - как только структуру базы меняешь, так все Brouse и Update в стандартных АБС-шаблонах все поля теряют. Чего то я потыркался, попыркался, да так и забросил это дело.

[FinSoft]

FinSoft, то есть у вас с выходом новой версии при изменении формата приходит дополнительный exe-шник, который запускается и конвертирует данные.
А как это может происходить организационно? Информационное письмо с просьбой запустить конвертор? Или как-то ещё?

И насколько проще модификация структур в случае выбора SQL, если нет удалённого доступа?

Да, конвертор всегда подкладывается к обновлению, даже если структура базы не менялась (клиенты же не обязательно на предыдущей версии работают). Клиентов не так много, поэтому обновления ставлю или сам, или ит-шники у клиентов, если такие есть. Со всеми есть удаленный доступ либо через radmin, либо через teamviwer. Сконвертить - просто запустить экзешник, но необходимо предварительно сделать бэкап базы и проверить, не работает ли кто с программой. Я делал специальную программку, которая умеет загружать обновление с ftp-сервера, проверять активных юзеров, бэкапить данные и устанавливать обновление, включая запуск конвертора и дополнительных программных патчей. Но еще как-то не прижилось, пока проще делать ручками. У основных клиентов сервера работают круглосуточно, обновляем с утра (часов в 7), когда еще никто не работает и все ночные расписания завершились. У мелких разогнать подключенных много времени не занимает (в программе есть мониторинг, кто работает, кто что редактирует, можно помотреть запущенные процессы, экран пользователя, разослать сообщения все подключенным или конкретному пользователю, сделать автоматическое отключение пользователей - это работает и в файл-серверном режиме). Само обновление ставится быстро. Основное время уходит на бэкап - это обычно просто копия всей папки с программой. Далее распаковываем файлики программы поверх старых, запускаем конвертор и патчер (если надо). Проверяем корректность, стартанув процедуру, в которой открываются все таблицы. На все про все обычно в пределах 5 мин.
С sql, наверно, обновлять структуру будет попроще, если не нужно выгонять всех активных пользователей. Хотя процесс все равно мутноватый получается, не факт, что старая версия программы будет корректно работать с измененной структурой базы. И саму программу обновлять, либо все равно пользователей разгонять, либо делать архитектуру с автосинхронизируемыми локальными копиями. И сам скрипт обновлений придется, скорее всего, ручками рихтовать.

[kreator]

Ну дык на терминальный режим перейти быстрее и безболезненней. Переписывать особо ничего не нужно. А с SQL... Пару лет назад пробовал через ОДБС поработать с MySql в Клаше 5,5. Работает, но лично у меня почему - то проблема следующего рода возникала - как только структуру базы меняешь, так все Brouse и Update в стандартных АБС-шаблонах все поля теряют. Чего то я потыркался, попыркался, да так и забросил это дело.

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

[Shur]

Я, к сожалению, с MySQL не работал. Только с MS SQL и давненько с Centura (через ODBC).
Нет оснований не доверять Optron'у. Может кто использовал связку MySQL+Кларион и знает в чём была заковыка?