forum.clarionlife.net

alex881 писал(а): ↑01 Июнь 2017, 19:27 цель - прокачаться в c#, java используя этот проект как основу, но для начала перенести таблицы в sql
Так то мне Сlarion нравиться, но его востребованность и моя ценность требуют освоения нового...и востребованного .

Надо продавать продукт. Или для начала его сделать на хорошем уровне. А устраивать баттлы - только время терять. Я на досуге почитываю sql.ru, вот там да, постоянно кто-то чем-то меряется. Для примера тема из последних - http://www.sql.ru/forum/1259865/na-chem ... t-qt-ili-c. Мне нравится слово "колхозить" . Обратите внимание - на втором листе кто-то Clarion предлагает (не я ).
Повторюсь и приведу свой пример. Сейчас работаю в крупном "холдинге". Эффективные IT-менеджеры даже не знают, что такое Кларион, главный периодически его называет Клиппером, говорит "Слезали бы с него. Что это?". Но когда они видят какой есть результат и за какие сроки и с какими ресурсами, всё встаёт на свои места. А рядом сидят "колхозники" на 1С, Джаве и c#, им ничего поручить нельзя, пальцы только гнут.
В нашей стране it-менеджеры, к сожалению, правят бал. Выставляют непонятные требования и надо им соответствовать. Раскрутили пару-тройку названий продуктов, сами составляют рейтинги и сами на них ссылаются.
И про Джаву. Оракл давно не выпускает обновлений. Джава-программисты на форуме обсуждают куда валить. Производители осей и браузеров отключают её поддержку. Как её (Джаву) можно рассматривать в качестве замены? Да, программистов много, они устраивают флеш-мобы всякие, чтобы продлить себе жизнь.

finsoftrz писал(а): ↑01 Июнь 2017, 17:26 Да, она такая. Там не просто шустрее работает, а на 2 порядка шустрее. Шустрее, чем на sql и сравнимо по надежности (особенно если лог приделать).

Вячеслав, а Вы вообще видели работу программы в связке ABC+SQL? Голословные какие-то факты. Вот у нас 150 одновременно работающих пользователей на говённом Файербёрде. Много пишут в базу, много аналитических запросов (не пару дней в конце месяца, а постоянно). Проблем особых нет. "Конкурирующий" продукт с вэб-мордой на связке .Net+MS SQL гораздо хуже по быстродействию. Хотя ему дали зелёную улицу (железо, каналы). Жалобы пользователей руководство достали, хотят переписывать. Не представляю на чём, но говорят на HTML5+JavaScript (кто-бы сомневался ). Кстати вся бизнес-логика у них на серваке (ХП, триггеры).
Другое дело, что, чтобы SQL взлетел, недостаточно просто базу туда кинуть. Нужно поработать над оптимизацией запросов, написать быстроработающих хранимок. Много чего нужно сделать. И в Кларионе нужно по-другому работать с SQL, много, оказывается, есть нюансов. Нужно голову поменять. SQL - совсем другой мир. Мне вот очень тяжело сейчас работать с TPS (если вдруг приходится). Не понимаю уже set/get. По какой таблице сначала идти, по какой потом...

kreator писал(а): ↑02 Июнь 2017, 6:20

finsoftrz писал(а): ↑01 Июнь 2017, 17:26 Да, она такая. Там не просто шустрее работает, а на 2 порядка шустрее. Шустрее, чем на sql и сравнимо по надежности (особенно если лог приделать).

Вячеслав, а Вы вообще видели работу программы в связке ABC+SQL? Голословные какие-то факты. Вот у нас 150 одновременно работающих пользователей на говённом Файербёрде. Много пишут в базу, много аналитических запросов (не пару дней в конце месяца, а постоянно). Проблем особых нет.

Почему голословные? Локальная работа с tps - это по сути база данных в памяти. И чтение, и запись кэшируются операционной системой. Что быстрее, работать с данными в оперативной памяти или извлекать их из sql сервера, да еще по сети? Когда пишут про медленную работу с tps, то всегда ссылаются на файл-шаринг. А когда про быструю с sql, то сравнивают полный перебор записей get/next и какой-нибудь закэшированный запрос, извлекающий одну итоговую цифру. Вот и вся математика...
На чем удобнее писать, конечно, больше вопрос привычки и имеющихся наработок. На tps не всегда set/next. Чаще вызовы ранее написанных процедур. Примитивные генерятся шаблонами, сложные пишутся вручную. Например, не надо каждый раз высчитывать оборотку по товарам, достаточно вызвать соответствующую функцию с кучкой различных параметров и получить результат в ту или иную кьюшку, с которой потом и работать. Запросы на sql в моем восприятии более громоздки и сложны в понимании. Когда многострочный запрос с кучей джоинов и юнионов, и таких запросов в реальном приложении сотни или даже тысячи, не думаю что это просто...
Потом, есть еще техническая поддержка пользователей. Одно дело, когда одна база данных и 150 пользователей, другое, когда 50 баз по 20 пользователей. Со встроенным форматом можно не беспокоиться, что у кого-то что-то пойдет не так, как на тестовой базе, а вот с sql можно быть в этом уверенным?
Если итожить, я не меряю, какая технология лучше в абсолютном понимании. Все зависит от целого ряда факторов. Прежде всего, от опыта, наработок и стиля мышления. Как говорят фитнес-тренеры, есть общие усредненные правила, но у каждого организм индивидуальный...
Основные проблемы с программами на c# и джаве, как мне представляется, в том, что это огромные глобальные фреймворки и пишущие на них не очень представляют, как что там работает. То есть смещение в сторону труда админов, так попробовал, вроде работает. А почему так, фик его знает, черный ящик...

Пару лет назад получил задание переписать чужое древнее приложение с Access, но "ни в коем случае не на Clarion". Древнее приложение имело пакостный интерфейс, дикие тормоза в работе, странную модель данных, отсутствие валидации ввода - всё такое... Поскольку "ни в коем случае" - сделал Web-приложение на python/django/mySQL с исправленной моделью данных, написал конвертор Access/Mysql, ну и собственно приложение, потом обвесил рюшечками (дозвон по телефону через asterisk, ajax, bootstrap - все дела...). Как только сделал - оказалось, что всех всё устраивало, нафиг вообще занимался...

Пока на начальном этапе переписывания app для работы "напрямую" через ODBC с mysql, до этого работало через MAV ODBC. Пока не вижу проблем все вроде стандартно, правда все было бы намного сложнее без IMDD Еще хочу с TPS перетащить на sqlite

finsoftrz писал(а): ↑02 Июнь 2017, 8:29

А сколько у вас внедрений в месяц? Тут просто есть такой нюанс - под это все нужно железо обязательно и настройка. У нас схема такая - в базе сидят в среднем 3-5 человек, но внедрений много, ну допустим одно в неделю в среднем. У многих сисадмина даже нет, есть эникейщик приходящий. Им если говорить, что покупайте отдельный сервак под продукт, они просто пошлют. А так ставишь MS SQL Express и оно работает десятилетиями, просто поставил и забыл. А с tps просто трэш был, какие-то только лечилки скриптовые не изобретали

gopstop2007 писал(а): ↑02 Июнь 2017, 10:51 Еще хочу с TPS перетащить на sqlite

Зачем? SQLite та же файл-серверная БД, что и TPS, только SQL-синтаксис понимает. И проблема Юникод, как обсуждали, стоит (могу быть неправ). Можно рассмотреть вариант Firebird, там есть режим embedded. Заодно и с MySQL слезть для унификации.

Yufil писал(а): ↑02 Июнь 2017, 10:32 Пару лет назад получил задание переписать чужое древнее приложение с Access, но "ни в коем случае не на Clarion".

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

RaFaeL писал(а): ↑02 Июнь 2017, 11:00 А с tps просто трэш был, какие-то только лечилки скриптовые не изобретали

Трэш как раз, если работать на обычном файл-сервере. В своё время в 1С тоже самое было. На "терминале" проблема снижается. Возможно, многократно снижается.

RaFaeL писал(а): ↑02 Июнь 2017, 11:00

finsoftrz писал(а): ↑02 Июнь 2017, 8:29

А сколько у вас внедрений в месяц? Тут просто есть такой нюанс - под это все нужно железо обязательно и настройка. У нас схема такая - в базе сидят в среднем 3-5 человек, но внедрений много, ну допустим одно в неделю в среднем. У многих сисадмина даже нет, есть эникейщик приходящий. Им если говорить, что покупайте отдельный сервак под продукт, они просто пошлют. А так ставишь MS SQL Express и оно работает десятилетиями, просто поставил и забыл. А с tps просто трэш был, какие-то только лечилки скриптовые не изобретали

Для 3-5 человек сервак не нужен. Практически любой новый комп потянет гораздо больше. Tsplus ставится за пару минут на любую настольную винду, в том числе и на home. Стоит немного, конечно, если лицензионность принципиальна. Зато поддерживать затем работу приложения надо не 3-5 компьютеров, а на одном. Если клиентов много, то снижение трудозатрат на суппорт в геометрической прогрессии... Но, опять таки, надо говорить о конкретных продуктах, их уровню сложности, функциональности, критичности для бизнеса клиентов. Например, может быть отдельный продукт, называемый CRM, а может быть, когда CRM лишь малая толика функционала...

у меня, к сожалению, и на терминалке tpsfix-ом приходилось базу лечить tps-ную, а она до 3 млн записей уже доросла....
приходилось ее с терминалки стягивать на локальный ssd винт и там лечить ибо в разы быстрее
собственно тоже одна из причин мигрировать на ms sql

По моему опыту, бывает такое, когда база ломается. В основном, по причине вырубания питания у сервера в неподходящий момент времени. Поэтому я приделал еще возможность восстановления из лога, не только tpsfix. Но если вырубить питание у сервера в неподходящий момент, то и любому sql серверу такое не понравится. А в каком случае затраты на восстановление работоспособности системы будут меньше, большой вопрос. Смотря, какие последствия у сбоя...

finsoftrz писал(а): ↑02 Июнь 2017, 11:40 По моему опыту, бывает такое, когда база ломается. В основном, по причине вырубания питания у сервера в неподходящий момент времени. Поэтому я приделал еще возможность восстановления из лога, не только tpsfix. Но если вырубить питание у сервера в неподходящий момент, то и любому sql серверу такое не понравится. А в каком случае затраты на восстановление работоспособности системы будут меньше, большой вопрос. Смотря, какие последствия у сбоя...

не, тут что то другое было, сервер терминальный точно не вырубался, возможно какие то косяки с райдом
а sql у нас вообще кластерный - если только обе ноды лягут по питанию, но это маловероятно

kreator писал(а): ↑02 Июнь 2017, 11:10 Зачем? SQLite та же файл-серверная БД, что и TPS, только SQL-синтаксис понимает. И проблема Юникод, как обсуждали, стоит (могу быть неправ). Можно рассмотреть вариант Firebird, там есть режим embedded. Заодно и с MySQL слезть для унификации.

Для sqlite не нужно устанавливать сервер и мне проще работать с запросами для выборки нужных данных, к тому один файл, вместо пачки TPS в плане создании много баз данных насчет unicode критично только для библиотек с названиями, пока пытаюсь найти решение и жду решения в виде С11. Насчет Filebird ничего против него не имею, но покажите хоть один хостинг с ним и сколько это стоит А на mysql пруд - пруди, кстати я бы полностью на него переполз, но есть проблемы с интернетом пока еще, думаю через пару лет уйдут.

finsoftrz писал(а): ↑02 Июнь 2017, 11:25Зато поддерживать затем работу приложения надо не 3-5 компьютеров, а на одном.

Зачем ее поддерживать? Поставил и забыл. Ставим только на "сервер" приложение, запуск с шары по сети с любого компьютера. Под "сервером" у некоторых вообще ноутбук )) Т.е. сегодня клиент платит, завтра ставим, послезавтра все работают, акты подписываем и о клиенте условно забыли по технической части. С tps так не выйдет

P.S. "Упавшую" базу в MS SQL за 15 лет видел один раз, да и то условно, перевели в какой-то безопасный режим на чтение и все данные вытянули, внезапные выключения питания на сервере на базу никакого влияния не оказывают

RaFaeL писал(а): ↑02 Июнь 2017, 12:01

finsoftrz писал(а): ↑02 Июнь 2017, 11:25Зато поддерживать затем работу приложения надо не 3-5 компьютеров, а на одном.

Зачем ее поддерживать? Поставил и забыл. Ставим только на "сервер" приложение, запуск с шары по сети с любого компьютера. Под "сервером" у некоторых вообще ноутбук )) Т.е. сегодня клиент платит, завтра ставим, послезавтра все работают, акты подписываем и о клиенте условно забыли по технической части. С tps так не выйдет

P.S. "Упавшую" базу в MS SQL за 15 лет видел один раз, да и то условно, перевели в какой-то безопасный режим на чтение и все данные вытянули, внезапные выключения питания на сервере на базу никакого влияния не оказывают

Я так и не понял, что не выйдет с tps. Вместе с настройкой tsplus уйдет минут 15, включая проверку работоспособности. Дальше уже обучение и консалтинг. Все удаленно...
По падению скульных баз как-то читал хвалебный отзыв клиента, работающего на одной "erp" системе под ораклом. Типа, у меня упала база, ребята все выходные толпой работали и восстановили к понедельнику. Очень квалифицированные, спасибо им большое...

У нас админ форматнул диск с рабочей БД. Конечно спаслись только бэкапом. По питанию могу сказать, тестил на SQLAnywhere. SQLAnywhere пишет лог, поэтому ему по барабану отрубание питания. Наверняка у всех больших также. Однажды сломалась БД на SQLAnywhere, хранящаяся на флешке (из-за флешки). Само всё восстановилось. Правда не в полном объёме, некоторые данные потерялись, но с работоспособностью всё равно нормально.