Special Enterprise Programming Olympics

[metaclass]

theiced и skif_by и artureg решили устроить соревнование на тему "какой язык программирования более адекватен в руках профессионала" и попросили придумать им задание. Поскольку синтетические задания с результатом в виде консольных утилит это скучно, а они все умеют веб хорошо, я им придумал задачку с не сильно сложным веб-приложением. Условие под катом:

Special Enterprise Programming Olympics

Problem 1:

You need to implement universal web-based application for report generation.

Application consists of:
* Database. You can use any relational DBMS you like, but you should have in mind ease of linux deployment.
* Web application deployed to your favorite web-server, app-server, whatever.
* Client-side JavaScript application working in modern browsers (>=IE7,Firefox>=5,Chrome)

* Web application must have report configuration file which contains:
** Unique system report id. Any string
** User-friendly name of report. For report titles and page headers.
** SQL query for report generation. SQL query is arbitrary and should contain parameters. SQL query will be in native format of used RDBMS.
** Query parameter description list.
Each parameter description contains parameter name, user-friendly caption,type,
output format and default value.
If you can infer parameter list from SQL query then this information is optional and
parameter list can be generated automatically.

** Query result field list. Field description should contain name, user-friendly name,
visibility flag(visible/not visible) and output format.
Field descriptions are optional - without description report should contain field
with default(returned from query) name and default output format.

* Types allowed for query parameters: integer,double,date,datetime,string,bool,decimal (money)

* Default values allowed for date or datetime parameters:
** Culture-invariant (!) string representation of any date or datetime
** If default value is prefixed with “@” then default parameter value is calculated as follows:
** @now - today (date) or current time(datetime)
** @prevmonthbeg - beginning of previous month
** @prevmonthend - end of previous month. Beware of difference in date and datetime (last day of month is 30/31, but last datetime of month is <00:00:00 01-of-nextmonth)
** @currmonthbeg - beginning of current month
** @currmonthend - end of current month
** @prevyearbeg - beginning of previous year
** @prevyearend - end of previous year
** @curryearbeg - beginning of current year
** @curryearend - end of current year

* Report configuration file will be edited once in a while based on
customers (report end-user) requirements.

Errors in configuration file format or in queries should be processed with
displaying of user-friendly error messages in client application and
error logging on server.


* Client application must show report list in any usable way(list of links, menu, tree, etc)
* Click on report must open report page which consists of:
** Report header (user-friendly report name)
** Report parameters table with user-friendly labels and editable parameters.
** "Refresh Report" button
** Report result table which is populated after click on "Refresh Report" button
or after Enter key press in any of parameter's edit controls.

* Paging or lazy result loading is not usually needed - most reports contains no more than 5 pages of data.

* When printing, report should follow the same structure as page, except for "Refresh" button.

* Report data is desirable to return in json or xml format, so it will be possible to
use wget/curl/any http client application to connect to server and get report data.


* Problem solution must contain:
** Deployment package for linux (any distro you like, but Ubuntu 10.04 LTS is preferred ). Also any deployment/configuration management system can be used.
** Deployment instructions.

Configuration file example: http://www.cacodaemon.org/content/so/ReportConfig.xml

Времени им - вообще до понедельника, но я бы добавил еще несколько дней на доработки по результатам.

Comments

[serbod.livejournal.com]

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

А тут то же самое, только через веб.

[metaclass.livejournal.com]

Тут не совсем такое: файлики в рантайме не меняются, юзерами выбираются отчеты и меняются их параметры.
А список доступных отчетов меняется при настройке системы.

[serbod.livejournal.com]

Хм, тогда непонятен смысл строить систему с нуля под файлы конфигурации заданной формы.

[metaclass.livejournal.com]

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

[serbod.livejournal.com]

Это-то понятно, непонятны жесткие требования к формату конфигов, которые только внутри системы используются. Впрочем, хозяин-барин. =)

[metaclass.livejournal.com]

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

[npocmu.livejournal.com]

Кроме таблиц отчетов не бывает? Данные всегда только с одного сервера одного типа тянутся? У нас ведь энтерпрайз, или как?

В жизни все гораздо сложнее и как результат проще взять готовое решение, благо они есть, чем изобретать велосипед.

[serbod.livejournal.com]

Там на не шибко мощном сервере была 1С 7.7, которая быстро работает только с локальной базой. И в которой если два отчета сразу запустить, то они будут формироваться на порядок дольше, чем те же два по-очереди. Так что ни SQL, ни терминал не прокатывает. Тем более, что отчеты были весьма большие и формировались минут 20-40.

Решение было простое - на клиентской машине было две кнопки в отчете - сформировать сразу и поставить в очередь. Если в очередь, то настройки отчета сохранялись в файл в папку на сервере. Сервер периодически заглядывал в эту папку, и формировал отчет с настройками из первого найденного файла, а сам файл удалял. Результат в виде готового отчета (с рамочками и группировками) сохранялся в XLS.

[serbod.livejournal.com]

Еще подобную хрень я делал в супер-базе.

Ситуация такая - есть десяток филиалов, в каждом своя автономная база. Каждый месяц все базы архивируются и обрезаются, то есть в каждой базе данные только за один месяц. Получается 12 баз в год на филиал, или примерно 120 баз в год всего. Базы эти приезжают в центральный филиал и складываются в отдельную папку. Потом данные из этих баз выдергивались и раскладывались по отдельным "чистовым" базам разных юр.лиц.

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

[npocmu.livejournal.com]

"Поскольку за месяц набиралось дофига данных и если все эти базы в одну сливать, то она будет еле ворочаться. "

Давно интересовало, откуда берутся такие странные представления о механизмах работы СУБД?

[metaclass.livejournal.com]

1С же. Кроме того, если не делать заранее рассчитанных агрегатов, данные лежат по страницам "плохо" или же фуллсканы в запросах - оно в итоге так и получается. Это все сдыхает тупо за счет i/o.

[npocmu.livejournal.com]

"Ситуация такая - есть десяток филиалов, в каждом своя автономная база. Каждый месяц все базы архивируются и обрезаются, то есть в каждой базе данные только за один месяц. Получается 12 баз в год на филиал, или примерно 120 баз в год всего. Базы эти приезжают в центральный филиал и складываются в отдельную папку. Потом данные из этих баз выдергивались и раскладывались по отдельным "чистовым" базам разных юр.лиц.

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


Где тут про 1С??? Тут только про тараканы в голове. Вместо организации нормального хранилища и OLAP поверх него - "запиливание" супербаз

[metaclass.livejournal.com]

http://metaclass.livejournal.com/658955.html?thread=11081227 "Там на не шибко мощном сервере была 1С 7.7, которая быстро работает только с локальной базой"
Я предполагаю, что "слияние баз филиалов" и тому подобное тоже делается для 1C.

[serbod.livejournal.com]

true =)

[serbod.livejournal.com]

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

[npocmu.livejournal.com]

"Перелить гигабайт мелких записей из одной базы в другую занимает прилично времени."

Ну если их програмно читать, затем програмно писать - то да. Но вообще-то есть инструменты в комплекте СУБД по пакетной (bulk) вставке записей. Работают они обычно практически сопоставимо со скоростью записи данных на жесткий диск

[serbod.livejournal.com]

В данном случае тупое копирование записей из таблицы в таблицу неприменимо.

У каждой базы есть таблицы клиентов и товаров. Частично они уникальны, частично нет - клиентов можно идентифицировать по ИНН/КПП, товары по штрихкоду. Есть еще куча нюансов, человеческого фактора и прочего говна, не позволяющего запросто взять и корректно консолидировать данные из автономных источников - будет рак и червие. То есть, нужны анальные огороды, проверки и костыли, в итоге консолидированные данные будут иметь отличия от первоисточника.

[serbod.livejournal.com]

Еще такой интересный момент - работа с несколькими базами легко распараллеливается без потерь производительности, за счет того, что базы могут лежать на разных носителях и общая скорость не упирается в iops носителя. =)

[npocmu.livejournal.com]

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

[serbod.livejournal.com]

Любой новый отчет - источник профита для программиста. Ну не учить же бухов и манагеров строить запросы на SQL.

[npocmu.livejournal.com]

Ну вообще-то анализировать данные, в то числе и средствами SQL это не работа для программиста. Программист только должен дать инструмент.
Загвоздка вот в чем - в нормально спроектированной БД, с 90% процентов реальных запросов, вполне способен справиться обслуживающий персонал, с применением штатных средств: анализатора/построителя запросов, построителя отчетов и т.д. А вот для хитровывернутых "оптимизированных" БД программист нужен на каждый новый чих.

ЗЫ Если чо, я "кровавый" (ТМ) энтерпрайз имею в виду. Где есть отделы разработки, сопровождения etc.

[npocmu.livejournal.com]

.. да, забыл упомянуть, то что таблицы ОДНОЙ БД могут лежать в разных файлах и на разных носителях, а индексы отдельно, и тоже в разных файлах и на разных носителях - это кагбэ штатная фича всех промышленных СУБД с незапамятных времен.

[metaclass.livejournal.com]

Кстате, да, партиционирование хитрожопое в таких случаях чрезвычайно спасает.

[serbod.livejournal.com]

А слабо на ходу поменять конфигурацию хранилищ БД? Мне не слабо, воткнул флешку с базами филиала, и они сразу готовы к работе. Не говоря уж о цене решения. =)

[metaclass.livejournal.com]

Тяжеловесные БД умеют на ходу менять. Но для этого к ним обязательно должен быть приставлен DBA за много денег, и сами базы тоже за много денег.