Язык для прикладных задач

[alexus]

Такие задачи составляют 95% от задач, которые приходится решать. И большая часть времени тратится программы при приёме данных на работу со строками...

Не очень понятно. Что имеется ввиду? Какие именно операции со строками?

Из БД выбирается информация, в том числе, строкового типа. Для каждой строки происходит операция выделения памяти. При этом, как правило, сканируется таблица строк. В результате всё это очень тормозит. Но речь о Delphi. Про 1С ничего сказать не могу.

...параллельно с получением и размещением данных выполняются и другие операции, установка признаков, калькуляция и т.п.

Ну а по ощущениям сколько времени тратится на этот код по отношению к выгребанию данных из базы с последующей записью результата?

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

Я вот сейчас дописываю расчет коммунальных услуг для водоканала. Город (120000 абонентов) обсчитывается за 5 минут. Код работает только 10% времени (1000 строк) Остальное время это выгребание исходных данных SQL'ом (примерно 30%) и запись результата расчета (примерно 60%). И это при том, что язык 1С примерно в 500 раз медленнее нативного.
Это не первый такой случай. Да и вообще я не помню, чтобы язык был узким местом. В подавляющем большинстве случаев виновником является ввод/вывод.

Может там запросы/структуры данных в БД не оптимизированы? Более минуты на чтение... как-то многовато. А запись - это вообще нонсенс. Если речь про MS SQL, то он в лидерах по добавлениям записей, на его основе даже real-time АСУТП-системы делают (например, Industrial SQL).

[Geniepro]

У меня тогда такой вопрос: Зачем мне прикладнику изучать монстра С++? Пусть он даже большинство плюшек скриптовых языков покроет? Смысл?

Низачем!!! Говорю же -- Дельфы, ДЕЛЬФЫ!!!
Ну или сишарп, если сишный синтаксис нравится (буээээ)...
Как вариант, если не хочется изучать это старинное унылое г -- то можно взять хаскель, правда под винду GUI и базы данных не так удобны, как в дельфях или шарпе...

[Geniepro]

Любой скриптовый язык имеет динамическую типизацию (хотя ничего не мешает сделать статическую)
Но! Не любой язык с динамической типизацией является скриптовым.

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

Еще попробую по пунктам пройтись.
1. Языки обычно простые для изучения и использования.
2. Переносимость выше чем у статических языков.
3. Непосредственный и естественный рефлекшн
4. Нет необходимости в использовании стека, т.к. скорость исполнения не имеет высокого приоритета. Можно использовать альтернативные более гибкие способы (как в JS например)
5. Нет необходимости в компиляции и линковке. Более того можно работать в режиме диалога (Python, Scheme)
6. Динамический язык обычно имеет богатое окружение в виде всяких контейнеров, коллекций и т.д., которых обычно с лихвой хватает для прикладных задач. Окружение пишется на нативных языках, и как следствие производительность оказывается достаточной для большинства прикладных задач. Прикладник не занимается разработкой сложных структур данных. Он пишет окружение только для своей конкретной прикладной задачи.

http://oberspace.dyndns.org/index.php/topic,286.0.html

[ilovb]

Может там запросы/структуры данных в БД не оптимизированы? Более минуты на чтение... как-то многовато. А запись - это вообще нонсенс. Если речь про MS SQL, то он в лидерах по добавлениям записей, на его основе даже real-time АСУТП-системы делают (например, Industrial SQL).

С запросами все нормально. Все необходимые кластерные и простые индексы присутствуют.
Насчет чтения... вы наверно выделяете отдельно размещение в памяти... Я же подразумеваю, что чтение окончено когда все данные находятся в оперативе. К тому же чтение у меня это SQL запросы с кучей соединений (все соединения конечно по индексам). Запросы выполняются минимальное число раз, т.е. каждый кусок данных выдирается сразу для всего города. Можно было и в один запрос сделать, но я решил, что читабельность важнее.
Насчет записи... Да, субд там MS SQL 2008. Но не забывайте что 1С это не прямая работа с таблицами. Там куча всяких обработчиков событий срабатывает (да и триггеров в субд тоже) К тому же 120000 нужно еще на 4 помножить, т.к. на каждого абонента пишется по 3-5 строк (есть несколько видов начислений). Результат пишется в документы, а скорость их записи много ниже чем у простой таблицы. В принципе можно писать в справочник (самая простая таблица 1С). Запись в этом случае будет происходить примерно с такой же скоростью, как при непосредственной работе с MS SQL, но это значит отказаться от плюшек 1С... А это уже не отличается от работы в Делфях Если в Дельфях написать подобие 1С-ных абстракций, то сомневаюсь, что оно будет быстрее работать.

[ilovb]

И на одном и том же объёме данных 1С работает очень неспешно, хотя там никакой аналитики нет, просто визуализация.

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

[alexus]

Может там запросы/структуры данных в БД не оптимизированы? Более минуты на чтение... как-то многовато. А запись - это вообще нонсенс. Если речь про MS SQL, то он в лидерах по добавлениям записей, на его основе даже real-time АСУТП-системы делают (например, Industrial SQL).

С запросами все нормально. Все необходимые кластерные и простые индексы присутствуют.
Насчет чтения... вы наверно выделяете отдельно размещение в памяти... Я же подразумеваю, что чтение окончено когда все данные находятся в оперативе.

Для меня запрос (время его срабатывания) - это одно, а размещение данных в памяти - другое. Тормозит именно размещение данных, а не СУБД, и не сеть. И при размещение тормозит из-за строк. Так у нас было.

К тому же чтение у меня это SQL запросы с кучей соединений (все соединения конечно по индексам). Запросы выполняются минимальное число раз, т.е. каждый кусок данных выдирается сразу для всего города. Можно было и в один запрос сделать, но я решил, что читабельность важнее.

Иногда быстрее бывает дёргать данные несколькими запросами, но к MS SQL это скорее всего не относится, у них мощный оптимизатор.

Насчет записи... Да, субд там MS SQL 2008. Но не забывайте что 1С это не прямая работа с таблицами. Там куча всяких обработчиков событий срабатывает (да и триггеров в субд тоже) К тому же 120000 нужно еще на 4 помножить, т.к. на каждого абонента пишется по 3-5 строк (есть несколько видов начислений). Результат пишется в документы, а скорость их записи много ниже чем у простой таблицы.

А документы - это не таблицы? (Конечно, один документ не в одной таблице хранится, но, видимо, Вы говорите о том, что есть промежуточный логический слой. Я правильно понял?)

В принципе можно писать в справочник (самая простая таблица 1С). Запись в этом случае будет происходить примерно с такой же скоростью, как при непосредственной работе с MS SQL, но это значит отказаться от плюшек 1С... А это уже не отличается от работы в Делфях Если в Дельфях написать подобие 1С-ных абстракций, то сомневаюсь, что оно будет быстрее работать.

А зачем они нужны эти абстракции? Какова их роль? (Я 1С совсем не знаю)

[alexus]

И на одном и том же объёме данных 1С работает очень неспешно, хотя там никакой аналитики нет, просто визуализация.

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

Не могу - не моя "епархия"...

[ilovb]

Тормозит именно размещение данных, а не СУБД, и не сеть. И при размещение тормозит из-за строк. Так у нас было.

Может и так. Но оно бы наверно от случая к случаю по разному тормозило, а я такого не наблюдал. В любом случае нет возможности на это влиять. И если бы даже была возможность, я бы не стал заниматься оптимизацией, т.к. у нас принято не усложнять код если проблема не критична (нет угрозы бизнесу клиента)

А документы - это не таблицы? (Конечно, один документ не в одной таблице хранится, но, видимо, Вы говорите о том, что есть промежуточный логический слой. Я правильно понял?)

Документ сам по себе не сильно сложный. Обычно это две таблицы (иногда больше) В одной таблице хранятся реквизиты документов, в остальных состав. Например для документа перемещения товара между складами будет две таблицы: в одной номер, дата, склад отправитель, склад получатель; во второй товар и количество. Т.е. одним документом можем переместить список товара. Сам по себе документ - это просто фиксация факта хозяйственной операции, и количество товара на складах он не меняет. Но документ после записи может быть переведен в состояние отражения операции в данных - это называется проведение. Проведение можно отменять.
Конкретно данные предприятия хранятся в специальных таблицах называемых регистрами. При проведении документ пишет свои данные в эти регистры (обычно в несколько). А вот регистр это уже сложная абстракция.

А зачем они нужны эти абстракции? Какова их роль? (Я 1С совсем не знаю)

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

ВЫБРАТЬ
   Номенклатура,
   КоличествоОстаток
ИЗ ТоварыНаСкладахОстатки(&Дата, Склад = &Склад)

Результат будет содержать остаток по каждому товару на данном складе.

А если сделать так

ВЫБРАТЬ
   Склад,
   Номенклатура,
   КоличествоОстаток
ИЗ ТоварыНаСкладахОстатки(&Дата)

То результат будет содержать остаток по каждому товару на каждом складе.

Т.е. регистры очень упрощают жизнь программисту. Тем более что на SQL нельзя рационально посчитать нарастащий итог. (как вы это в Делфи делаете ума не приложу  подозреваю что сочиняете подобие 1С-ного регистра  )

[alexus]

Документ сам по себе не сильно сложный. Обычно это две таблицы (иногда больше) В одной таблице хранятся реквизиты документов, в остальных состав. Например для документа перемещения товара между складами будет две таблицы: в одной номер, дата, склад отправитель, склад получатель; во второй товар и количество. Т.е. одним документом можем переместить список товара. Сам по себе документ - это просто фиксация факта хозяйственной операции, и количество товара на складах он не меняет. Но документ после записи может быть переведен в состояние отражения операции в данных - это называется проведение. Проведение можно отменять.
Конкретно данные предприятия хранятся в специальных таблицах называемых регистрами. При проведении документ пишет свои данные в эти регистры (обычно в несколько). А вот регистр это уже сложная абстракция.

Это, видимо, от "бухгалтерии" идёт. В реальной жизни не слишком нужная и полезная вещь. Для примера на производстве сотни операций, между которыми передаются сотни партий полуфабрикатов каждую смену. И тоже надо знать остатки (незавершённое производство). Фиксировать всё это в регистрах с привязкой к операциям/участкам в виде остатков. Зачем?

А зачем они нужны эти абстракции? Какова их роль? (Я 1С совсем не знаю)

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

ВЫБРАТЬ
   Номенклатура,
   КоличествоОстаток
ИЗ ТоварыНаСкладахОстатки(&Дата, Склад = &Склад)

Результат будет содержать остаток по каждому товару на данном складе.

А если сделать так

ВЫБРАТЬ
   Склад,
   Номенклатура,
   КоличествоОстаток
ИЗ ТоварыНаСкладахОстатки(&Дата)

То результат будет содержать остаток по каждому товару на каждом складе.

Т.е. регистры очень упрощают жизнь программисту. Тем более что на SQL нельзя рационально посчитать нарастащий итог. (как вы это в Делфи делаете ума не приложу  подозреваю что сочиняете подобие 1С-ного регистра  )

В чём здесь упрощение?
Дело не Delphi, на Delphi пишется интерфейс между БД и пользователем.
В БД фиксируется движение материалов: приход расход, на основе документов (накладных, актов оприходывания и списания). При этом, позиции документов по приходу и расходу могут хранится в одной таблице. Есть таблица инвентаризации, в которой фиксируются фактические остатки материалов на конкретные: дату и время. Если нужен остаток материала на некоторую дату, то из таблицы инвентаризации поднимается дата+время проведения инвентаризации и количество материала по факту инвентаризации. Остаётся только посчитать сумму приходов и расходов по нужному материалу между датой+временем инвентаризации и заданной датой. (Можно и данные инвентаризации хранить в той же таблице движения материалов, но это несколько запутывает логику). Такая простая система позволяет проводить простую и скользящую инвентаризации, получать остатки, а также позволяет делать надстройки, например, размещение материалов по местам хранения, снятие материалов с мест хранения, учёт заполненности мест хранения и склада в целом, оптимизацию маршрутов складского транспорта и пр., и пр.).
Но ничто не мешает иметь дополнительно таблицу остатков, которая заполняется автоматически - триггерами, по фактам перемещения товаров (приход/уход). Мы таких таблиц не используем, поскольку при номенклатуре в десятки тысяч позиций, программа работает достаточно быстро.

[ilovb]

Документ - это просто удобная абстракция. Хозяйственную операцию как правило нужно отражать в нескольких таблицах (например покупка товара - это запись в две таблицы (поступление на склад и взаиморасчеты с поставщиком)), а документ избавляет от этой работы. К тому же документ не обязательно сразу проводить, если он не полностью заполнен, а у вас кончился рабочий день. В этом случае вы его сохраняете, чтобы "добить" на следующий день.

Если нужен остаток материала на некоторую дату, то из таблицы инвентаризации поднимается дата+время проведения инвентаризации и количество материала по факту инвентаризации. Остаётся только посчитать сумму приходов и расходов по нужному материалу между датой+временем инвентаризации и заданной датой.

Так и есть. Изобретаете подобие 1С-ного регистра (он примерно так и работает)

Понятно, что можно сделать точно такой-же механизм (а можно и круче). Но прикладник не должен этим заниматься.

[alexus]

Если нужен остаток материала на некоторую дату, то из таблицы инвентаризации поднимается дата+время проведения инвентаризации и количество материала по факту инвентаризации. Остаётся только посчитать сумму приходов и расходов по нужному материалу между датой+временем инвентаризации и заданной датой.

Так и есть. Изобретаете подобие 1С-ного регистра (он примерно так и работает)

Это не 1С - это жизнь. И до появления компьютеров так работали.

Понятно, что можно сделать точно такой-же механизм (а можно и круче). Но прикладник не должен этим заниматься.

А чем должен заниматься прикладник?

[ilovb]

Это не 1С - это жизнь. И до появления компьютеров так работали.

Кто ж спорит? Просто в 1С никто не занимается изобретением велосипедов, которые уже давно изобретены 

А чем должен заниматься прикладник?

Решением прикладных задач. Механизм расчета нарастающего итога в СУБД - это системная задача.
Провести четкую границу между системным и прикладным программированием довольно сложно. Но я придерживаюсь концепции механика и водителя.
Водитель не должен заниматься обслуживанием автомобиля (системное программирование). Он должен управлять автомобилем (прикладное программирование)

Прикладник решает человеческие проблемы, а системщик системные. Механик обеспечивает работу техники, а водитель обеспечивает доставку груза.

[alexus]

Это не 1С - это жизнь. И до появления компьютеров так работали.

Кто ж спорит? Просто в 1С никто не занимается изобретением велосипедов, которые уже давно изобретены 

Ну, и напрасно. Не изобретя "велосипед", вообще ничего не изобретёшь. Это раз.
Изобретая "велосипед", можно изобрести и принципиально новую конструкцию и получить массу положительных "побочных" эффектов. Это два.
И, наконец, речь фактически идёт о моделировании и проектировании БД. А процесс моделирования очень важен, поскольку в этот момент появляется и решается огромное количество проблем. Если стадии моделирования нет, то те же проблемы всплывут значительно позже и их устранение будет существенно боле затратной операцией. Это три.

А чем должен заниматься прикладник?

Решением прикладных задач.

Какие задачи Вы считаете прикладными?

[ilovb]

И, наконец, речь фактически идёт о моделировании и проектировании БД.

Какое отношение это имеет к структуре БД?

Какие задачи Вы считаете прикладными?

Я уже говорил выше. Это конкретные практические человеческие проблемы.

[Geniepro]

Какие задачи Вы считаете прикладными?

Я уже говорил выше. Это конкретные практические человеческие проблемы.

То есть бухучёт? ))