Сообщение Re[7]: Опять поднимают про low-code и помоечку для средняков от 18.09.2021 0:42
Изменено 18.09.2021 0:45 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 день выучить.
Если мне так и так нужно разбираться с ключами, в чём тогда смысл платформы? На практике это вырождается в то, что нужен будет программист на этом визуальном псевдо-языке, ну и по всем кочкам. Дешевле нанять 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 день выучить.
Если мне так и так нужно разбираться с ключами, в чём тогда смысл платформы? На практике это вырождается в то, что нужен будет программист на этом визуальном псевдо-языке, ну и по всем кочкам. Дешевле нанять 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. Зачем нужен мастер форм? Если уж использовать мастер вообще (а не инспектор свойств, например), то это должен быть мастер представлений.