Сообщение Re[7]: Опять поднимают про low-code и помоечку для средняков от 18.09.2021 0:42
Изменено 18.09.2021 0:57 Shtole
Re[7]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, vdimas, Вы писали:
V>А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?
Например, через формульные колонки и колонки-ссылки.
Условия, column set, сортировка, группировка — через представления. (Посмотрите, например, в Outlook. Только там всё гвоздями прибито. Зачем-то). Сложные условия — тоже через формульные колонки.
Но вообще это надо на конкретных примерах рассматривать.
S>>Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы.
V>Это тебе.
V>А далёким от программирования проще визуально накидать сущности, заодно увидев связи м/у ними, т.к. GUI-редактор запроса может сразу соединять внешние ключи.
Смотря что понимать под словом «визуально». Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.
S>>И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».
V>Вызов тыжпрограммиста 1С обходится слишком дорого.
Так вроде про SQL-запросы речь шла? Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
У них своя система (буква С в слове СУБД), своё видение, и про них мне не очень интересно.
S>>Упомянутый выше Access, кстати, такой же. По крайней мере, был. (У меня старая версия). Не успел я создать таблицу, как он ошарашил меня вопросом, не хочу ли я задать ключевые поля для установления связей. Выносить в интерфейс такие вещи для меня выглядит очень странно.
V>Это та самая автоматизация рутины.
V>В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))
Так дело же не в том, что «мышкой нащёлкать». Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее. Щёлкаешь на кнопку — у тебя текст копипастится в запрос. Как на Спектруме. Вообще, вот это и есть мой point: вместо того, чтобы думать и делать хороший UI на замену DSL/ЯП, люди берут понятия программирования и делают так, чтобы их можно было мышкой нащёлкивать. То есть, идут по пути наименьшего сопротивления. Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.
Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии? Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей? Или в почтовом клиенте/органайзере они есть? Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля. Текст я понял так, что без них, мол, связи установить не смогу. Страшно. Вдруг мне эти связи понадобятся? Нуок, я нажимаю «Да» — бамс! Держи колонку «Код» на самом видном месте. Ну хорошо, можно, оказывается, скрыть эту колонку, если щёлкнуть по ней ПКМ. То есть, сначала меня заставляют создать ненужную для моих целей колонку, а потом искать, как её скрыть. И в той версии Access, что у меня, нет возможности скрыть эту колонку от бухгалтера, но оставить для администратора (т.е. представлений). Флаги отображения колонок глобальны, их возможные значения ни к чему не привязаны.
На всякий случай: я просто описываю то, что видит пользователь.
Короче, чтобы не перепираться тут до бесконечности. Просто посмотрите, как это сделано в Шарике. Там много умного придумано по сравнению с Access. Но колонка Id, ЕМНИП, у них тоже на самом видном месте. Ну и вообще — Шарик (был?) просто игрушкой. Чтобы можно было хоть как-то им пользоваться, я его дорабатывал в своё время с помощью хранимок, триггеров, SQLCLR и такой-то матери (напрямую работая с MS SQL, да — через их API практически полезные сценарии заведомо реализовать нельзя было), но так и не смог получить приличную производительность. Плюс у них некоторые моменты принципиально неправильно сделаны. CAML — их DSL для управления данными — был полное позорище (мааааааленькое подмножество SQL зачем-то завернули в XML), объектная модель (для того самого low code) — тоже. Ну, может с тех пор его в чём-то улучшили, но для no-code/low-code я его НЕ посоветовал бы ни при каких раскладах.
S>>Предметно-ориентированные среды легче позиционировать, да.
V>И ими легче пользоваться.
V>Для сред более широкого назначения не обойтись без большой сетки чего-то вроде "шаблонов пустых приложений".
S>>Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок.
V>Да ладно.
V>А шкафчик свой в Архикаде нарисовать?
V>А здание в виде спирали и волн, построить там все балки?
V>Всё более-менее серьезные такие вещи представляют из себя инструмент для очень продвинутого юзверя, что MS Access, что Архикад.
V>А непритязательные могут и SketchUp-ом побавляться, эдаким блокнотиком для зарисовок.
Ну и где там no-code/low-code? Вы просто берёте готовый продукт (Архикад) и юзаете as is. No-code/low-code это, скорее, когда берёте универсальную платформу. Создаёте структуру, представления, условия, ограничения, шаблоны, валидаторы, извещения, отправку документов и т.п. — всё это без программирования. И получаете конкретно заточенную под ваши юз-кейсы систему.
V>Но вы же знаете, что идеал нам только снится
V>Ну, активная работа идёт.
V>По крайней мере в строительных САПР-ах.
V>Можно накидать свой проект, выложить онлайн и дать клиенту сылку — он как в в трехмерной игре может побродить по будущему дому, потыкать по реквизитам, сопоставлять планы и "ощущения" от 3D.
V>Вот ролик аж на 4 минуты:
V>https://www.youtube.com/watch?v=9sUQYtSKYw0
V>Рекомендую не пролистывать, а вытерпеть все 4 минуты, там ничего лишнего. ))
Зачем я это терпел 4 минуты? В смысле, где там no-code/low-code? Просто раньше в комплекте с редактором — например, тем же Excel'ем — шёл облегчённый viewer, чтобы юзер не обламывался, получив по почте .xls. Иногда можно было сгенерировать viewer с одним-единственным документом (как в PowerPoint). Ну вот, а эти сделали облегчённый viewer чисто в браузере и дали возможность публиковать документы через своё облако. Ну, молодцы. (Наверно). Хотя я бы лично такое не купил, потому, что даже облако выбрать нельзя. Но это к делу не относится. Что там именно no-code/low-code? В UE4, для сравнения, хоть BluePrint есть. Он всяко к теме больше отношения имеет.
V>>>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
V>>>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
S>>А какой именно идее? Как вы её сформулируете?
V>Я уже формулировал — автоматизация рутины или облегчение взаимодействия с ней.
Слишком общо.
S>>Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. Оттого, что он завёрнут в мастер, он не перестанет быть программистским мусором.
V>Ничего не понял.
V>Что такое "программистский мусор"?
S>>Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.
V>А как жить без внешних ключей? ))
V>Без внешних ключей не нужна никакая реляционная база, можно пользоваться нереляционной.
Внешние ключи это и есть программистский мусор, который не надо тащить в UI. Давайте возьмём пример из Википедии.
Вместо всего этого ужаса можно же просто:
а) Сделать CITY не таблицей, а колонкой-перечислением (enum'ом) в таблице с адресами. Для юзера это самое естественное. Контроль ссылочной целостности надо привязать к редактированию колонки, предлагая разумные опции в контексте операции: чем заменить удаляемое значение, если оно используется? На практике же это для чего нужно: какая-нибудь ворона забила три москвы, на все три куча ссылок в адресах, их надо смерджить. Удаляем их по одной, нас спрашивают, что использовать вместо — оба раза выбираем правильную. (Или, допустим, пустое значение — но это если колонка может быть пустой, т.е. допускаются адреса без города).
Сравните теперь, как выглядят сценарии на основе внешних ключей для юзера:
Блин, тут прямо не знаешь, что и выбрать — один вариант лучше другого!
б) Как только окажется, что у нас есть 2 разные таблицы с городами, т.е. список городов нужен более одного раза, во избежание копипаста преобразуем колонку «Город» в шаблон колонки «Город». Далее, заменяем исходную колонку-перечисление на шаблонную колонку, указав вновь созданный шаблон. Ну и затем во второй таблице создаём на основе шаблона ещё одну колонку с городами. При редактировании шаблона... См. выше.
S>>По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс.
V>Да ладно, чтобы освоить такую хрень как суррогатный ключ любому не-дебилу нужно примерно 10 минут.
V>Все хотя бы слышали такие слова как нумерация, артикул, инвентарный номер и т.д., поэтому проблем не возникает.
Ага. А сиплюсплюс можно за 21 день выучить.
Если мне так и так нужно разбираться с ключами, в чём тогда смысл платформы? Она меня огородит от необходимости изучать синтаксис SQL? Но ведь дело-то не в синтаксисе, а в идеях, которые через него выражаются. На практике это приведёт к тому, что нужен будет программист на этом визуальном псевдо-языке, ну и по всем кочкам. Дешевле нанять fullstack (SQL/сервер/клиент) разработчика.
S>>И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.
V>Читаю, и такое ощущение, что впечатления твои слишком свежи.
V>Не могу заставить себя всерьз погрузиться в эти мелочи, бо еще лет 20 назад тщательно их проехал.
Подождите минутку. Впечатления свежи, потому, что я, раз уж тут заговорили про Access, специально его открыл и включил юзера. Чтобы разговор не был голословным. Чтобы на примерах.
Но ведь эти примеры не просто так, они показывают принципиальный подход разрабов. Вот о нём мы и говорим. На конкретных примерах. Конкретные примеры за 20 лет могут устареть, но подход-то останется. Если в новом Access именно подход поменялся по сравнению с той версией, которая у меня, так и напишите.
S>>Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области.
V>1. Проще убрать готовое поле из представления, чем непонятно как его добавить, особенно в первые дни работы с такими продуктами.
V>2. В любом случае существует некий мастер форм, где отмечаются поля, которые юзверь желает видеть на форме или в таблице.
1. А ещё лучше (не проще, а лучше) не отображать его ни в дефолтном представлении, ни по дефолту в новых представлениях.
2. Зачем нужен мастер форм? Если уж использовать мастер вообще (а не инспектор свойств, например), то это должен быть мастер представлений.
V>А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?
Например, через формульные колонки и колонки-ссылки.
Условия, column set, сортировка, группировка — через представления. (Посмотрите, например, в Outlook. Только там всё гвоздями прибито. Зачем-то). Сложные условия — тоже через формульные колонки.
Но вообще это надо на конкретных примерах рассматривать.
S>>Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы.
V>Это тебе.
V>А далёким от программирования проще визуально накидать сущности, заодно увидев связи м/у ними, т.к. GUI-редактор запроса может сразу соединять внешние ключи.
Смотря что понимать под словом «визуально». Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.
S>>И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».
V>Вызов тыжпрограммиста 1С обходится слишком дорого.
Так вроде про SQL-запросы речь шла? Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
У них своя система (буква С в слове СУБД), своё видение, и про них мне не очень интересно.
S>>Упомянутый выше Access, кстати, такой же. По крайней мере, был. (У меня старая версия). Не успел я создать таблицу, как он ошарашил меня вопросом, не хочу ли я задать ключевые поля для установления связей. Выносить в интерфейс такие вещи для меня выглядит очень странно.
V>Это та самая автоматизация рутины.
V>В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))
Так дело же не в том, что «мышкой нащёлкать». Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее. Щёлкаешь на кнопку — у тебя текст копипастится в запрос. Как на Спектруме. Вообще, вот это и есть мой point: вместо того, чтобы думать и делать хороший UI на замену DSL/ЯП, люди берут понятия программирования и делают так, чтобы их можно было мышкой нащёлкивать. То есть, идут по пути наименьшего сопротивления. Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.
Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии? Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей? Или в почтовом клиенте/органайзере они есть? Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля. Текст я понял так, что без них, мол, связи установить не смогу. Страшно. Вдруг мне эти связи понадобятся? Нуок, я нажимаю «Да» — бамс! Держи колонку «Код» на самом видном месте. Ну хорошо, можно, оказывается, скрыть эту колонку, если щёлкнуть по ней ПКМ. То есть, сначала меня заставляют создать ненужную для моих целей колонку, а потом искать, как её скрыть. И в той версии Access, что у меня, нет возможности скрыть эту колонку от бухгалтера, но оставить для администратора (т.е. представлений). Флаги отображения колонок глобальны, их возможные значения ни к чему не привязаны.
На всякий случай: я просто описываю то, что видит пользователь.
Короче, чтобы не перепираться тут до бесконечности. Просто посмотрите, как это сделано в Шарике. Там много умного придумано по сравнению с Access. Но колонка Id, ЕМНИП, у них тоже на самом видном месте. Ну и вообще — Шарик (был?) просто игрушкой. Чтобы можно было хоть как-то им пользоваться, я его дорабатывал в своё время с помощью хранимок, триггеров, SQLCLR и такой-то матери (напрямую работая с MS SQL, да — через их API практически полезные сценарии заведомо реализовать нельзя было), но так и не смог получить приличную производительность. Плюс у них некоторые моменты принципиально неправильно сделаны. CAML — их DSL для управления данными — был полное позорище (мааааааленькое подмножество SQL зачем-то завернули в XML), объектная модель (для того самого low code) — тоже. Ну, может с тех пор его в чём-то улучшили, но для no-code/low-code я его НЕ посоветовал бы ни при каких раскладах.
S>>Предметно-ориентированные среды легче позиционировать, да.
V>И ими легче пользоваться.
V>Для сред более широкого назначения не обойтись без большой сетки чего-то вроде "шаблонов пустых приложений".
S>>Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок.
V>Да ладно.
V>А шкафчик свой в Архикаде нарисовать?
V>А здание в виде спирали и волн, построить там все балки?
V>Всё более-менее серьезные такие вещи представляют из себя инструмент для очень продвинутого юзверя, что MS Access, что Архикад.
V>А непритязательные могут и SketchUp-ом побавляться, эдаким блокнотиком для зарисовок.
Ну и где там no-code/low-code? Вы просто берёте готовый продукт (Архикад) и юзаете as is. No-code/low-code это, скорее, когда берёте универсальную платформу. Создаёте структуру, представления, условия, ограничения, шаблоны, валидаторы, извещения, отправку документов и т.п. — всё это без программирования. И получаете конкретно заточенную под ваши юз-кейсы систему.
V>Но вы же знаете, что идеал нам только снится
V>Ну, активная работа идёт.
V>По крайней мере в строительных САПР-ах.
V>Можно накидать свой проект, выложить онлайн и дать клиенту сылку — он как в в трехмерной игре может побродить по будущему дому, потыкать по реквизитам, сопоставлять планы и "ощущения" от 3D.
V>Вот ролик аж на 4 минуты:
V>https://www.youtube.com/watch?v=9sUQYtSKYw0
V>Рекомендую не пролистывать, а вытерпеть все 4 минуты, там ничего лишнего. ))
Зачем я это терпел 4 минуты? В смысле, где там no-code/low-code? Просто раньше в комплекте с редактором — например, тем же Excel'ем — шёл облегчённый viewer, чтобы юзер не обламывался, получив по почте .xls. Иногда можно было сгенерировать viewer с одним-единственным документом (как в PowerPoint). Ну вот, а эти сделали облегчённый viewer чисто в браузере и дали возможность публиковать документы через своё облако. Ну, молодцы. (Наверно). Хотя я бы лично такое не купил, потому, что даже облако выбрать нельзя. Но это к делу не относится. Что там именно no-code/low-code? В UE4, для сравнения, хоть BluePrint есть. Он всяко к теме больше отношения имеет.
V>>>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
V>>>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
S>>А какой именно идее? Как вы её сформулируете?
V>Я уже формулировал — автоматизация рутины или облегчение взаимодействия с ней.
Слишком общо.
S>>Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. Оттого, что он завёрнут в мастер, он не перестанет быть программистским мусором.
V>Ничего не понял.
V>Что такое "программистский мусор"?
S>>Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.
V>А как жить без внешних ключей? ))
V>Без внешних ключей не нужна никакая реляционная база, можно пользоваться нереляционной.
Внешние ключи это и есть программистский мусор, который не надо тащить в UI. Давайте возьмём пример из Википедии.
Вместо всего этого ужаса можно же просто:
а) Сделать CITY не таблицей, а колонкой-перечислением (enum'ом) в таблице с адресами. Для юзера это самое естественное. Контроль ссылочной целостности надо привязать к редактированию колонки, предлагая разумные опции в контексте операции: чем заменить удаляемое значение, если оно используется? На практике же это для чего нужно: какая-нибудь ворона забила три москвы, на все три куча ссылок в адресах, их надо смерджить. Удаляем их по одной, нас спрашивают, что использовать вместо — оба раза выбираем правильную. (Или, допустим, пустое значение — но это если колонка может быть пустой, т.е. допускаются адреса без города).
Сравните теперь, как выглядят сценарии на основе внешних ключей для юзера:
Если для внешнего ключа разрешено удаление по цепочке, то вместе с удалением Владивостока будут удалены улицы Светланская и Пушкинская с ID=3.
Если для внешнего ключа запрещено удаление по цепочке, то операция вызовет ошибку нарушения ссылочной целостности, так как в таблице STREET будут находиться улицы с кодом ID_CITY=3, который отсутствует в таблице CITY.
Блин, тут прямо не знаешь, что и выбрать — один вариант лучше другого!
б) Как только окажется, что у нас есть 2 разные таблицы с городами, т.е. список городов нужен более одного раза, во избежание копипаста преобразуем колонку «Город» в шаблон колонки «Город». Далее, заменяем исходную колонку-перечисление на шаблонную колонку, указав вновь созданный шаблон. Ну и затем во второй таблице создаём на основе шаблона ещё одну колонку с городами. При редактировании шаблона... См. выше.
S>>По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс.
V>Да ладно, чтобы освоить такую хрень как суррогатный ключ любому не-дебилу нужно примерно 10 минут.
V>Все хотя бы слышали такие слова как нумерация, артикул, инвентарный номер и т.д., поэтому проблем не возникает.
Ага. А сиплюсплюс можно за 21 день выучить.
Если мне так и так нужно разбираться с ключами, в чём тогда смысл платформы? Она меня огородит от необходимости изучать синтаксис SQL? Но ведь дело-то не в синтаксисе, а в идеях, которые через него выражаются. На практике это приведёт к тому, что нужен будет программист на этом визуальном псевдо-языке, ну и по всем кочкам. Дешевле нанять fullstack (SQL/сервер/клиент) разработчика.
S>>И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.
V>Читаю, и такое ощущение, что впечатления твои слишком свежи.
V>Не могу заставить себя всерьз погрузиться в эти мелочи, бо еще лет 20 назад тщательно их проехал.
Подождите минутку. Впечатления свежи, потому, что я, раз уж тут заговорили про Access, специально его открыл и включил юзера. Чтобы разговор не был голословным. Чтобы на примерах.
Но ведь эти примеры не просто так, они показывают принципиальный подход разрабов. Вот о нём мы и говорим. На конкретных примерах. Конкретные примеры за 20 лет могут устареть, но подход-то останется. Если в новом Access именно подход поменялся по сравнению с той версией, которая у меня, так и напишите.
S>>Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области.
V>1. Проще убрать готовое поле из представления, чем непонятно как его добавить, особенно в первые дни работы с такими продуктами.
V>2. В любом случае существует некий мастер форм, где отмечаются поля, которые юзверь желает видеть на форме или в таблице.
1. А ещё лучше (не проще, а лучше) не отображать его ни в дефолтном представлении, ни по дефолту в новых представлениях.
2. Зачем нужен мастер форм? Если уж использовать мастер вообще (а не инспектор свойств, например), то это должен быть мастер представлений.
Re[7]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, vdimas, Вы писали:
V>А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?
Например, через формульные колонки и колонки-ссылки.
Условия, column set, сортировка, группировка — через представления. (Посмотрите, например, в Outlook. Только там всё гвоздями прибито. Зачем-то). Сложные условия — тоже через формульные колонки.
Но вообще это надо на конкретных примерах рассматривать.
S>>Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы.
V>Это тебе.
V>А далёким от программирования проще визуально накидать сущности, заодно увидев связи м/у ними, т.к. GUI-редактор запроса может сразу соединять внешние ключи.
Смотря что понимать под словом «визуально». Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.
S>>И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».
V>Вызов тыжпрограммиста 1С обходится слишком дорого.
Так вроде про SQL-запросы речь шла? Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
У них своя система (буква С в слове СУБД), своё видение, и про них мне не очень интересно.
S>>Упомянутый выше Access, кстати, такой же. По крайней мере, был. (У меня старая версия). Не успел я создать таблицу, как он ошарашил меня вопросом, не хочу ли я задать ключевые поля для установления связей. Выносить в интерфейс такие вещи для меня выглядит очень странно.
V>Это та самая автоматизация рутины.
V>В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))
Так дело же не в том, что «мышкой нащёлкать». Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее. Щёлкаешь на кнопку — у тебя текст копипастится в запрос. Как на Спектруме. Вообще, вот это и есть мой point: вместо того, чтобы думать и делать хороший UI на замену DSL/ЯП, люди берут понятия программирования и делают так, чтобы их можно было мышкой нащёлкивать. То есть, идут по пути наименьшего сопротивления. Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.
Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии? Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей? Или в почтовом клиенте/органайзере они есть? Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля. Текст я понял так, что без них, мол, связи установить не смогу. Страшно. Вдруг мне эти связи понадобятся? Нуок, я нажимаю «Да» — бамс! Держи колонку «Код» на самом видном месте. Ну хорошо, можно, оказывается, скрыть эту колонку, если щёлкнуть по ней ПКМ. То есть, сначала меня заставляют создать ненужную для моих целей колонку, а потом искать, как её скрыть. И в той версии Access, что у меня, нет возможности скрыть эту колонку от бухгалтера, но оставить для администратора (т.е. представлений). Флаги отображения колонок глобальны, их возможные значения ни к чему не привязаны.
На всякий случай: я просто описываю то, что видит пользователь.
Короче, чтобы не перепираться тут до бесконечности. Просто посмотрите, как это сделано в Шарике. Там много умного придумано по сравнению с Access. Но колонка Id, ЕМНИП, у них тоже на самом видном месте. Ну и вообще — Шарик (был?) просто игрушкой. Чтобы можно было хоть как-то им пользоваться, я его дорабатывал в своё время с помощью хранимок, триггеров, SQLCLR и такой-то матери (напрямую работая с MS SQL, да — через их API практически полезные сценарии заведомо реализовать нельзя было), но так и не смог получить приличную производительность. Плюс у них некоторые моменты принципиально неправильно сделаны. CAML — их DSL для управления данными — был полное позорище (мааааааленькое подмножество SQL зачем-то завернули в XML), объектная модель (для того самого low code) — тоже. Ну, может с тех пор его в чём-то улучшили, но для no-code/low-code я его НЕ посоветовал бы ни при каких раскладах.
S>>Предметно-ориентированные среды легче позиционировать, да.
V>И ими легче пользоваться.
V>Для сред более широкого назначения не обойтись без большой сетки чего-то вроде "шаблонов пустых приложений".
S>>Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок.
V>Да ладно.
V>А шкафчик свой в Архикаде нарисовать?
V>А здание в виде спирали и волн, построить там все балки?
V>Всё более-менее серьезные такие вещи представляют из себя инструмент для очень продвинутого юзверя, что MS Access, что Архикад.
V>А непритязательные могут и SketchUp-ом побавляться, эдаким блокнотиком для зарисовок.
Ну и где там no-code/low-code? Вы просто берёте готовый продукт (Архикад) и юзаете as is. No-code/low-code это, скорее, когда берёте универсальную платформу. Создаёте структуру, представления, условия, ограничения, шаблоны, валидаторы, извещения, отправку документов и т.п. — всё это без программирования. И получаете конкретно заточенную под ваши юз-кейсы систему.
V>Но вы же знаете, что идеал нам только снится
V>Ну, активная работа идёт.
V>По крайней мере в строительных САПР-ах.
V>Можно накидать свой проект, выложить онлайн и дать клиенту сылку — он как в в трехмерной игре может побродить по будущему дому, потыкать по реквизитам, сопоставлять планы и "ощущения" от 3D.
V>Вот ролик аж на 4 минуты:
V>https://www.youtube.com/watch?v=9sUQYtSKYw0
V>Рекомендую не пролистывать, а вытерпеть все 4 минуты, там ничего лишнего. ))
Зачем я это терпел 4 минуты? В смысле, где там no-code/low-code? Просто раньше в комплекте с редактором — например, тем же Excel'ем — шёл облегчённый viewer, чтобы юзер не обламывался, получив по почте .xls. Иногда можно было сгенерировать viewer с одним-единственным документом (как в PowerPoint). Ну вот, а эти сделали облегчённый viewer чисто в браузере и дали возможность публиковать документы через своё облако. Ну, молодцы. (Наверно). Хотя я бы лично такое не купил, потому, что даже облако выбрать нельзя. Но это к делу не относится. Что там именно no-code/low-code? В UE4, для сравнения, хоть BluePrint есть. Он всяко к теме больше отношения имеет.
V>>>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
V>>>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
S>>А какой именно идее? Как вы её сформулируете?
V>Я уже формулировал — автоматизация рутины или облегчение взаимодействия с ней.
Слишком общо.
S>>Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. Оттого, что он завёрнут в мастер, он не перестанет быть программистским мусором.
V>Ничего не понял.
V>Что такое "программистский мусор"?
S>>Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.
V>А как жить без внешних ключей? ))
V>Без внешних ключей не нужна никакая реляционная база, можно пользоваться нереляционной.
Внешние ключи это и есть программистский мусор, который не надо тащить в UI. Давайте возьмём пример из Википедии.
Вместо всего этого ужаса можно же просто:
а) Сделать CITY не таблицей, а колонкой-перечислением (enum'ом) в таблице с адресами. Для юзера это самое естественное. Контроль ссылочной целостности надо привязать к редактированию колонки, предлагая разумные опции в контексте операции: чем заменить удаляемое значение, если оно используется? На практике же это для чего нужно: какая-нибудь ворона забила три москвы, на все три куча ссылок в адресах, их надо смерджить. Удаляем их по одной, нас спрашивают, что использовать вместо — оба раза выбираем правильную. (Или, допустим, пустое значение — но это если колонка может быть пустой, т.е. допускаются адреса без города).
Сравните теперь, как выглядят сценарии на основе внешних ключей для юзера:
Блин, тут прямо не знаешь, что и выбрать — один вариант лучше другого!
б) Как только окажется, что у нас есть 2 разные таблицы с городами, т.е. список городов нужен более одного раза, во избежание копипаста преобразуем колонку «Город» в шаблон колонки «Город». Далее, заменяем исходную колонку-перечисление на шаблонную колонку, указав вновь созданный шаблон. Ну и затем во второй таблице создаём на основе шаблона ещё одну колонку с городами. При редактировании шаблона... См. выше.
S>>По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс.
V>Да ладно, чтобы освоить такую хрень как суррогатный ключ любому не-дебилу нужно примерно 10 минут.
V>Все хотя бы слышали такие слова как нумерация, артикул, инвентарный номер и т.д., поэтому проблем не возникает.
Ага. А сиплюсплюс можно за 21 день выучить.
Если мне так и так нужно разбираться с ключами, в чём тогда смысл платформы? Она меня огородит от необходимости изучать синтаксис SQL? Но ведь дело-то не в синтаксисе, а в идеях, которые через него выражаются. На практике это приведёт к тому, что нужен будет программист на этом визуальном псевдо-языке, ну и по всем кочкам. Дешевле нанять fullstack (SQL/сервер/клиент) разработчика.
S>>И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.
V>Читаю, и такое ощущение, что впечатления твои слишком свежи.
V>Не могу заставить себя всерьз погрузиться в эти мелочи, бо еще лет 20 назад тщательно их проехал.
Подождите минутку. Впечатления свежи, потому, что я, раз уж тут заговорили про Access, специально его открыл и включил юзера. Чтобы разговор не был голословным. Чтобы на примерах.
Но ведь эти примеры не просто так, они показывают принципиальный подход разрабов. Вот о нём мы и говорим. На конкретных примерах. Конкретные примеры за 20 лет могут устареть, но подход-то останется. Если в новом Access именно подход поменялся по сравнению с той версией, которая у меня, так и напишите.
S>>Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области.
V>1. Проще убрать готовое поле из представления, чем непонятно как его добавить, особенно в первые дни работы с такими продуктами.
V>2. В любом случае существует некий мастер форм, где отмечаются поля, которые юзверь желает видеть на форме или в таблице.
1. А ещё лучше (не проще, а лучше) не отображать его ни в дефолтном представлении, ни по дефолту в новых представлениях. И не задавать глупых вопросов. И автоматически задействовать его для ссылок, оставив юзеру только выбрать способ репрезентации записи.
2. Зачем нужен мастер форм? Если уж использовать мастер вообще (а не инспектор свойств, например), то это должен быть мастер представлений.
V>А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?
Например, через формульные колонки и колонки-ссылки.
Условия, column set, сортировка, группировка — через представления. (Посмотрите, например, в Outlook. Только там всё гвоздями прибито. Зачем-то). Сложные условия — тоже через формульные колонки.
Но вообще это надо на конкретных примерах рассматривать.
S>>Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы.
V>Это тебе.
V>А далёким от программирования проще визуально накидать сущности, заодно увидев связи м/у ними, т.к. GUI-редактор запроса может сразу соединять внешние ключи.
Смотря что понимать под словом «визуально». Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.
S>>И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».
V>Вызов тыжпрограммиста 1С обходится слишком дорого.
Так вроде про SQL-запросы речь шла? Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
У них своя система (буква С в слове СУБД), своё видение, и про них мне не очень интересно.
S>>Упомянутый выше Access, кстати, такой же. По крайней мере, был. (У меня старая версия). Не успел я создать таблицу, как он ошарашил меня вопросом, не хочу ли я задать ключевые поля для установления связей. Выносить в интерфейс такие вещи для меня выглядит очень странно.
V>Это та самая автоматизация рутины.
V>В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))
Так дело же не в том, что «мышкой нащёлкать». Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее. Щёлкаешь на кнопку — у тебя текст копипастится в запрос. Как на Спектруме. Вообще, вот это и есть мой point: вместо того, чтобы думать и делать хороший UI на замену DSL/ЯП, люди берут понятия программирования и делают так, чтобы их можно было мышкой нащёлкивать. То есть, идут по пути наименьшего сопротивления. Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.
Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии? Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей? Или в почтовом клиенте/органайзере они есть? Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля. Текст я понял так, что без них, мол, связи установить не смогу. Страшно. Вдруг мне эти связи понадобятся? Нуок, я нажимаю «Да» — бамс! Держи колонку «Код» на самом видном месте. Ну хорошо, можно, оказывается, скрыть эту колонку, если щёлкнуть по ней ПКМ. То есть, сначала меня заставляют создать ненужную для моих целей колонку, а потом искать, как её скрыть. И в той версии Access, что у меня, нет возможности скрыть эту колонку от бухгалтера, но оставить для администратора (т.е. представлений). Флаги отображения колонок глобальны, их возможные значения ни к чему не привязаны.
На всякий случай: я просто описываю то, что видит пользователь.
Короче, чтобы не перепираться тут до бесконечности. Просто посмотрите, как это сделано в Шарике. Там много умного придумано по сравнению с Access. Но колонка Id, ЕМНИП, у них тоже на самом видном месте. Ну и вообще — Шарик (был?) просто игрушкой. Чтобы можно было хоть как-то им пользоваться, я его дорабатывал в своё время с помощью хранимок, триггеров, SQLCLR и такой-то матери (напрямую работая с MS SQL, да — через их API практически полезные сценарии заведомо реализовать нельзя было), но так и не смог получить приличную производительность. Плюс у них некоторые моменты принципиально неправильно сделаны. CAML — их DSL для управления данными — был полное позорище (мааааааленькое подмножество SQL зачем-то завернули в XML), объектная модель (для того самого low code) — тоже. Ну, может с тех пор его в чём-то улучшили, но для no-code/low-code я его НЕ посоветовал бы ни при каких раскладах.
S>>Предметно-ориентированные среды легче позиционировать, да.
V>И ими легче пользоваться.
V>Для сред более широкого назначения не обойтись без большой сетки чего-то вроде "шаблонов пустых приложений".
S>>Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок.
V>Да ладно.
V>А шкафчик свой в Архикаде нарисовать?
V>А здание в виде спирали и волн, построить там все балки?
V>Всё более-менее серьезные такие вещи представляют из себя инструмент для очень продвинутого юзверя, что MS Access, что Архикад.
V>А непритязательные могут и SketchUp-ом побавляться, эдаким блокнотиком для зарисовок.
Ну и где там no-code/low-code? Вы просто берёте готовый продукт (Архикад) и юзаете as is. No-code/low-code это, скорее, когда берёте универсальную платформу. Создаёте структуру, представления, условия, ограничения, шаблоны, валидаторы, извещения, отправку документов и т.п. — всё это без программирования. И получаете конкретно заточенную под ваши юз-кейсы систему.
V>Но вы же знаете, что идеал нам только снится
V>Ну, активная работа идёт.
V>По крайней мере в строительных САПР-ах.
V>Можно накидать свой проект, выложить онлайн и дать клиенту сылку — он как в в трехмерной игре может побродить по будущему дому, потыкать по реквизитам, сопоставлять планы и "ощущения" от 3D.
V>Вот ролик аж на 4 минуты:
V>https://www.youtube.com/watch?v=9sUQYtSKYw0
V>Рекомендую не пролистывать, а вытерпеть все 4 минуты, там ничего лишнего. ))
Зачем я это терпел 4 минуты? В смысле, где там no-code/low-code? Просто раньше в комплекте с редактором — например, тем же Excel'ем — шёл облегчённый viewer, чтобы юзер не обламывался, получив по почте .xls. Иногда можно было сгенерировать viewer с одним-единственным документом (как в PowerPoint). Ну вот, а эти сделали облегчённый viewer чисто в браузере и дали возможность публиковать документы через своё облако. Ну, молодцы. (Наверно). Хотя я бы лично такое не купил, потому, что даже облако выбрать нельзя. Но это к делу не относится. Что там именно no-code/low-code? В UE4, для сравнения, хоть BluePrint есть. Он всяко к теме больше отношения имеет.
V>>>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
V>>>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
S>>А какой именно идее? Как вы её сформулируете?
V>Я уже формулировал — автоматизация рутины или облегчение взаимодействия с ней.
Слишком общо.
S>>Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. Оттого, что он завёрнут в мастер, он не перестанет быть программистским мусором.
V>Ничего не понял.
V>Что такое "программистский мусор"?
S>>Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.
V>А как жить без внешних ключей? ))
V>Без внешних ключей не нужна никакая реляционная база, можно пользоваться нереляционной.
Внешние ключи это и есть программистский мусор, который не надо тащить в UI. Давайте возьмём пример из Википедии.
Вместо всего этого ужаса можно же просто:
а) Сделать CITY не таблицей, а колонкой-перечислением (enum'ом) в таблице с адресами. Для юзера это самое естественное. Контроль ссылочной целостности надо привязать к редактированию колонки, предлагая разумные опции в контексте операции: чем заменить удаляемое значение, если оно используется? На практике же это для чего нужно: какая-нибудь ворона забила три москвы, на все три куча ссылок в адресах, их надо смерджить. Удаляем их по одной, нас спрашивают, что использовать вместо — оба раза выбираем правильную. (Или, допустим, пустое значение — но это если колонка может быть пустой, т.е. допускаются адреса без города).
Сравните теперь, как выглядят сценарии на основе внешних ключей для юзера:
Если для внешнего ключа разрешено удаление по цепочке, то вместе с удалением Владивостока будут удалены улицы Светланская и Пушкинская с ID=3.
Если для внешнего ключа запрещено удаление по цепочке, то операция вызовет ошибку нарушения ссылочной целостности, так как в таблице STREET будут находиться улицы с кодом ID_CITY=3, который отсутствует в таблице CITY.
Блин, тут прямо не знаешь, что и выбрать — один вариант лучше другого!
б) Как только окажется, что у нас есть 2 разные таблицы с городами, т.е. список городов нужен более одного раза, во избежание копипаста преобразуем колонку «Город» в шаблон колонки «Город». Далее, заменяем исходную колонку-перечисление на шаблонную колонку, указав вновь созданный шаблон. Ну и затем во второй таблице создаём на основе шаблона ещё одну колонку с городами. При редактировании шаблона... См. выше.
S>>По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс.
V>Да ладно, чтобы освоить такую хрень как суррогатный ключ любому не-дебилу нужно примерно 10 минут.
V>Все хотя бы слышали такие слова как нумерация, артикул, инвентарный номер и т.д., поэтому проблем не возникает.
Ага. А сиплюсплюс можно за 21 день выучить.
Если мне так и так нужно разбираться с ключами, в чём тогда смысл платформы? Она меня огородит от необходимости изучать синтаксис SQL? Но ведь дело-то не в синтаксисе, а в идеях, которые через него выражаются. На практике это приведёт к тому, что нужен будет программист на этом визуальном псевдо-языке, ну и по всем кочкам. Дешевле нанять fullstack (SQL/сервер/клиент) разработчика.
S>>И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.
V>Читаю, и такое ощущение, что впечатления твои слишком свежи.
V>Не могу заставить себя всерьз погрузиться в эти мелочи, бо еще лет 20 назад тщательно их проехал.
Подождите минутку. Впечатления свежи, потому, что я, раз уж тут заговорили про Access, специально его открыл и включил юзера. Чтобы разговор не был голословным. Чтобы на примерах.
Но ведь эти примеры не просто так, они показывают принципиальный подход разрабов. Вот о нём мы и говорим. На конкретных примерах. Конкретные примеры за 20 лет могут устареть, но подход-то останется. Если в новом Access именно подход поменялся по сравнению с той версией, которая у меня, так и напишите.
S>>Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области.
V>1. Проще убрать готовое поле из представления, чем непонятно как его добавить, особенно в первые дни работы с такими продуктами.
V>2. В любом случае существует некий мастер форм, где отмечаются поля, которые юзверь желает видеть на форме или в таблице.
1. А ещё лучше (не проще, а лучше) не отображать его ни в дефолтном представлении, ни по дефолту в новых представлениях. И не задавать глупых вопросов. И автоматически задействовать его для ссылок, оставив юзеру только выбрать способ репрезентации записи.
2. Зачем нужен мастер форм? Если уж использовать мастер вообще (а не инспектор свойств, например), то это должен быть мастер представлений.