Здравствуйте, Shtole, Вы писали:

V>>А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.
V>>Многие такие менеджеры еще позволяют графически конструировать запросы.
S>Зачем пользователю графически конструировать запросы?

А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?


S>Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы.

Это тебе.
А далёким от программирования проще визуально накидать сущности, заодно увидев связи м/у ними, т.к. GUI-редактор запроса может сразу соединять внешние ключи.


S>И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».

Вызов тыжпрограммиста 1С обходится слишком дорого.


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

Это та самая автоматизация рутины.
В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))


S>Их много, и хотя форм-фактор «конструктор сайтов» уже идёт вразрез с идеей того, что я делаю, я буду благодарен (чисто для расширения кругозора) за любые примеры того, как описанную функциональность можно сделать в других местах.

Для этого хотелось бы увидеть "описанную функциональность".
Конструкторы сайтов очень разные.


S>Например, какие шаблоны они понимают? Txt, HTML, pdf? Что-то ещё? Какой синтаксис используют для разметки?

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


S>Предметно-ориентированные среды легче позиционировать, да.

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


S>Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок.

Да ладно.
А шкафчик свой в Архикаде нарисовать?
А здание в виде спирали и волн, построить там все балки?

Все более-менее серьезные такие вещи представляют из себя инструмент для очень продвинутого юзверя, что MS Access, что Архикад.
А непритязательные могут и SketchUp-ом побавляться, эдаким блокнотиком для зарисовок.


S>Но вы же знаете, что идеал нам только снится

Ну, активная работа идёт.
По крайней мере в строительных САПР-ах.
Можно накидать свой проект, выложить онлайн и дать клиенту сылку — он как в в трехмерной игре может побродить по будущему дому, потыкать по реквизитам, сопоставлять планы и "ощущения" от 3D.

Вот ролик аж на 4 минуты:
https://www.youtube.com/watch?v=9sUQYtSKYw0

Рекомендую не пролистывать, а вытерпеть все 4 минуты, там ничего лишнего. ))


V>>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
V>>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
S>А какой именно идее? Как вы её сформулируете?

Я уже формулировал — автоматизация рутины или облегчение взаимодействия с ней.
В первом же P-CAD можно было создавать свои блоки (макросы) из готовых элементов и использовать их затем.
Т.е. не надо повторяющиеся части схем каждй раз заново вводить.

Параметрические 3D САПР.
Параметрические — ключевое, поменял пару св-в и всё может быть пересчитано и поменяться до неузнаваемости.

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

Кульманом на ватмане это перерисовывать бесконечно.
В обычных 3D рисовалках, типа SketchUp — тоже.
А тут лениво мышкой можно гонять многие тысячи комбинаторных сочетаний всего со всем.


S>Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. Оттого, что он завёрнут в мастер, он не перестанет быть программистским мусором.

Ничего не понял.
Что такое "программистский мусор"?


S>Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.

А как жить без внешних ключей? ))
Без внешних ключей не нужна никакая реляционная база, можно пользоваться нереляционной.


S>По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс.

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


S>И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.

Читаю, и такое ощущение, что впечатления твои слишком свежи.
Не могу заставить себя всерьз погрузиться в эти мелочи, бо еще лет 20 назад тщательно их проехал.


S>Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области.

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