![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Special Enterprise Programming Olympics
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
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
Времени им - вообще до понедельника, но я бы добавил еще несколько дней на доработки по результатам.
no subject
Давно интересовало, откуда берутся такие странные представления о механизмах работы СУБД?
no subject
no subject
Поскольку за месяц набиралось дофига данных и если все эти базы в одну сливать, то она будет еле ворочаться. Да и по соображениям коммерческой безопасности вредно было держать столько говна в одном флаконе. Так что была запилена супер-база, которая не являлось базой данных, а была надстройкой над кучей баз данных. То есть, если нужно было сформировать отчет по каким-то условиям, то она поочереди открывала доступные базы данных, запускала в каждой этот отчет, а результаты склеивала в один большой отчет."
Где тут про 1С??? Тут только про тараканы в голове. Вместо организации нормального хранилища и OLAP поверх него - "запиливание" супербаз
no subject
Я предполагаю, что "слияние баз филиалов" и тому подобное тоже делается для 1C.
no subject
no subject
no subject
Ну если их програмно читать, затем програмно писать - то да. Но вообще-то есть инструменты в комплекте СУБД по пакетной (bulk) вставке записей. Работают они обычно практически сопоставимо со скоростью записи данных на жесткий диск
no subject
У каждой базы есть таблицы клиентов и товаров. Частично они уникальны, частично нет - клиентов можно идентифицировать по ИНН/КПП, товары по штрихкоду. Есть еще куча нюансов, человеческого фактора и прочего говна, не позволяющего запросто взять и корректно консолидировать данные из автономных источников - будет рак и червие. То есть, нужны анальные огороды, проверки и костыли, в итоге консолидированные данные будут иметь отличия от первоисточника.
no subject
no subject
То есть любой запрос вида "выдать итоги за 10 лет просуммированные по кварталам" превращается в неплохой источник профита для прикладного программиста.
no subject
no subject
Загвоздка вот в чем - в нормально спроектированной БД, с 90% процентов реальных запросов, вполне способен справиться обслуживающий персонал, с применением штатных средств: анализатора/построителя запросов, построителя отчетов и т.д. А вот для хитровывернутых "оптимизированных" БД программист нужен на каждый новый чих.
ЗЫ Если чо, я "кровавый" (ТМ) энтерпрайз имею в виду. Где есть отделы разработки, сопровождения etc.
no subject
no subject
no subject
С точки зрения юзера - это такой же отчет, как и другие, ничего волшебного. Единственная магия - флешку с базами конкретного филиала за конкретный период вставить, иначе никакого фокуса не получится. Флешки у главбуха, выдаются только по делу. Это вам не огороды городить с правами доступа к общей свалке.
no subject
Я понимаю, конечно, гордость за изобретение "супербазы" на флешке, но пора бы уже из детсадовских штанишек вырастать.
no subject
На периферийных базах ведется учет всех оттенков серого. А в "чистовые" базы из периферии заливаются только "правильные" документы. Лично я это называю консолидацией.
В случае формирования отчетов, некоторые отчеты формировались в "нативном" формате каждой базы, с учетом местной специфики. "Агрегировать" их в принципе невозможно, да и не нужно.
А прочие аналитические отчеты выдергивали данные во временную таблицу, затем эта таблица группировалась и сортировалась, и выводилась в кошерном формате
no subject
no subject
Ошибаетесь, по-крайней мере у меня этим занимаются обычные инженеры по обслуживанию информационной системы.
(no subject)
(no subject)
no subject
no subject
no subject
no subject
no subject
В моем случае, даже если выдернуть флешку с базой во время формирования отчета, ничего страшного не случится - зафиксирует ошибку и возьмется за следующую базу. Фишка в том, что базы открываются не в основном приложении, а в отдельных экзеплярах с доступом по COM/OLE.
no subject