SimpleQueryBuilder - простой Х++ конструктор читабельных T-SQL запросов

[mazzy]

Цитата:

Сообщение от Ruff

Но тут я вижу немного другое назначение - улучшить читабельность кода

хотел удержаться... но не удержался...
обещал не использовать термин "программистский подход"...
Про программистский подход, программистское мышление и стереотипы
но ту тему тоже создал некий пользователь Ruff )))))

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

1.
писать запросы в коде, со всеми полям, join'ами, условиями на поля... само по себе неблагодарное дело. программист тратит свое время не на "читабельность", а на то, чтобы вспомнить обязательные таблицы в join, обязательные связи между таблицами, обязательные поля группировок, непустые поля...

пример? до 2009 включительно номенклатура состоит из 8 таблиц. 3 из которых обязательны, а одна из них должна джойнится три раза с разными условиями.
навскидку запрос напишите?

а в 2012 и дальше ввели общие для всех компаний продукты и вместо номенклатуры "используемые продукты" по отдельным компаниям. там порядка 20 таблиц.
навскидку запрос напишите?

"читабельность кода" - очень малая часть трудозатрат.
нужны пресеты для работы с логическими сущностями.

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

читабельность кода? ха-ха-ха-ха!!!!
нужны удобные алиасы для полей и таблиц (особенно внешних).
нужны пресеты для сущностей вместо обращения к отдельным таблицам

например, сущность "номенклатура" - состоит из...
с сущностью "номенклатура" можно работать так то...

3.
во внешних системах и внешних программах часто используются дефиниции таблиц и связей в json- или xml-файлах. (см. например, java-проект Hibernate, http://devcolibri.com/1394 ).
использование таких дефиниций на порядки более упросит жизнь программиста, нежели пресловутая "читаемость кода"

4.
реально упросить жизнь программисту можно одним способом - снизить сложность используемых программистом сущностей.

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

далее нужен код типа:

Query q1 = new QueryBuilder::constructFromPreset(mySuperPreset1);
Query q2 = new QueryBuilder::addFromPreset(q1, mySuperPreset2);

примерно так.

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

но на практике программисту проще написать
str s = strfmt("select %1 from %2 %3 %4 where %5", fields, tableWithAlias, orders, groups, whereclause);
чем разбираться с очередным билдером, который занимается только "читабельностью кода"

)))

[belugin]

Цитата:

Сообщение от mazzy

но на практике программисту проще написать
str s = strfmt("select %1 from %2 %3 %4 where %5", fields, tableWithAlias, orders, groups, whereclause);
чем разбираться с очередным билдером, который занимается только "читабельностью кода"

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

Если это умозрительная конструкция, хотелось бы в этой фразе заменить "на практике" на "в теории".

[belugin]

Цитата:

Сообщение от mazzy

что нужно:
= работа с пресетами сущностей, вместо работы с отдельными нормализованными(!) таблицами (как целиком, так и с частью запроса. см. например, InventSum::initQueryFrom)

См. также DataEntities в Ax7

Цитата:

Сообщение от документация

...
A data entity is an abstraction from the physical implementation of database tables. For example, in normalized tables, a lot of the data for each customer might be stored in a customer table, and then the rest might be spread across a small set of related tables. In this case, the data entity for the customer concept appears as one de-normalized view, in which each row contains all the data from the customer table and its related tables.

A data entity encapsulates a business concept into a format that makes development and integration easier. The abstracted nature of a data entity can simplify application development and customization. Later, the abstraction also insulates application code from the inevitable churn of the physical tables from version to version of Microsoft Dynamics AX.

To summarize: Data entity provides conceptual abstraction and encapsulation (de-normalized view) of underlying table schemas to represent key data concepts and functionalities.
...