Сообщение Re[5]: Опять поднимают про low-code и помоечку для средняков от 17.09.2021 19:02
Изменено 17.09.2021 19:46 Shtole
Re[5]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, vdimas, Вы писали:
V>Да понятно, но в БД тоже имена, типы...
V>А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.
V>Многие такие менеджеры еще позволяют графически конструировать запросы.
Зачем пользователю графически конструировать запросы?
Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы. И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».
Упомянутый выше Access, кстати, такой же. По крайней мере, был. (У меня старая версия). Не успел я создать таблицу, как он ошарашил меня вопросом, не хочу ли я задать ключевые поля для установления связей. Выносить в интерфейс такие вещи для меня выглядит очень странно.
S>>Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа.
V>А современные конструкторы сайтов смотрел?
Их много, и хотя форм-фактор «конструктор сайтов» уже идёт вразрез с идеей того, что я делаю, я буду благодарен (чисто для расширения кругозора) за любые примеры того, как описанную функциональность можно сделать в других местах. Например, какие шаблоны они понимают? Txt, HTML, pdf? Что-то ещё? Какой синтаксис используют для разметки?
V>Ну, кое-какие алгоритмы ему знать надо, из разряда что делает тот или иной "кубик" системы (кнопка, команда, режим, их св-ва, как взаимодействует и т.д.)
Я стараюсь исходить из потребностей. В данном случае, как я вижу, есть потребность иметь по каждой строке (описывающей, например, транзакцию) пригодный для печати отчёт (платёжку, счёт, whatever), доступный прямо из таблицы. Соответственно, так это и представлено в UI: добавление колонки типа «Отчёт», для чего нужно выполнить одно действие (не считая задавания имени колонки): выбрать файл с шаблоном. Но, возможно, я в плену предубеждений и можно сделать то же самое понятнее для юзера.
V>Да, юзверь в таких системах работает с предметно-ориентированной средой, заточенной на решение некоего класса задач, т.е. работает с достаточно высокоуровневыми "алгоритмами" и в тех условиях, что околосистемные вещи "кто-то" за него уже решил.
Возможно, что я ошибаюсь, но как раз «предметная ориентированность» и губит все такие продукты. Выше давали ссылку на менеджер чеков для tax return, экспат в Германию описывает свои с ней приключения.
Предметно-ориентированные среды легче позиционировать, да. (То есть, «предметная ориентированность» вообще не про продукт, а про маркетинг — тот же SharePoint как только не впаривали, и как «веб-портал», и как СКД, и как чёрта в ступе, однако его техническая суть от этого не меняется). Но поскольку сама предметная область — понятие расплывчатое, если слишком углубиться в этом направлении, по ходу пьесы часто оказывается, что (в рамках той же предметной области!) сделано много неуниверсальных предположений, введено много ненужных ограничений и так далее.
Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок. Но вы же знаете, что идеал нам только снится
V>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
V>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
А какой именно идее? Как вы её сформулируете?
Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. От того, что он завёрнут в мастер, он не перестанет быть программистским мусором.
Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.
По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс. И на передний план выходят вопросы, странные для программиста, но очевидные для юзера, например, сохранять ли форматирование при подстановке, если да — от какого представления (если, конечно, в UI вообще есть представления).
Репрезентативное поле, в отличие от ключевого, для пользователя имеет смысл только в контексте ссылающейся таблицы. Знать его, создавая справочник, невозможно. (Потому, что невозможно заранее знать все сценарии использования справочника, на то он и справочник).
И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.
Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области. Что юзер должен с этой колонкой делать? Она же чисто техническая! И нужна, как правило, для стыковки с другими системами. Но совать её в интерфейс на самом первом (то есть, самом дорогом) месте — извините.
Как-то так.
V>Да понятно, но в БД тоже имена, типы...
V>А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.
V>Многие такие менеджеры еще позволяют графически конструировать запросы.
Зачем пользователю графически конструировать запросы?
Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы. И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».
Упомянутый выше Access, кстати, такой же. По крайней мере, был. (У меня старая версия). Не успел я создать таблицу, как он ошарашил меня вопросом, не хочу ли я задать ключевые поля для установления связей. Выносить в интерфейс такие вещи для меня выглядит очень странно.
S>>Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа.
V>А современные конструкторы сайтов смотрел?
Их много, и хотя форм-фактор «конструктор сайтов» уже идёт вразрез с идеей того, что я делаю, я буду благодарен (чисто для расширения кругозора) за любые примеры того, как описанную функциональность можно сделать в других местах. Например, какие шаблоны они понимают? Txt, HTML, pdf? Что-то ещё? Какой синтаксис используют для разметки?
V>Ну, кое-какие алгоритмы ему знать надо, из разряда что делает тот или иной "кубик" системы (кнопка, команда, режим, их св-ва, как взаимодействует и т.д.)
Я стараюсь исходить из потребностей. В данном случае, как я вижу, есть потребность иметь по каждой строке (описывающей, например, транзакцию) пригодный для печати отчёт (платёжку, счёт, whatever), доступный прямо из таблицы. Соответственно, так это и представлено в UI: добавление колонки типа «Отчёт», для чего нужно выполнить одно действие (не считая задавания имени колонки): выбрать файл с шаблоном. Но, возможно, я в плену предубеждений и можно сделать то же самое понятнее для юзера.
V>Да, юзверь в таких системах работает с предметно-ориентированной средой, заточенной на решение некоего класса задач, т.е. работает с достаточно высокоуровневыми "алгоритмами" и в тех условиях, что околосистемные вещи "кто-то" за него уже решил.
Возможно, что я ошибаюсь, но как раз «предметная ориентированность» и губит все такие продукты. Выше давали ссылку на менеджер чеков для tax return, экспат в Германию описывает свои с ней приключения.
Предметно-ориентированные среды легче позиционировать, да. (То есть, «предметная ориентированность» вообще не про продукт, а про маркетинг — тот же SharePoint как только не впаривали, и как «веб-портал», и как СКД, и как чёрта в ступе, однако его техническая суть от этого не меняется). Но поскольку сама предметная область — понятие расплывчатое, если слишком углубиться в этом направлении, по ходу пьесы часто оказывается, что (в рамках той же предметной области!) сделано много неуниверсальных предположений, введено много ненужных ограничений и так далее.
Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок. Но вы же знаете, что идеал нам только снится
V>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
V>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
А какой именно идее? Как вы её сформулируете?
Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. От того, что он завёрнут в мастер, он не перестанет быть программистским мусором.
Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.
По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс. И на передний план выходят вопросы, странные для программиста, но очевидные для юзера, например, сохранять ли форматирование при подстановке, если да — от какого представления (если, конечно, в UI вообще есть представления).
Репрезентативное поле, в отличие от ключевого, для пользователя имеет смысл только в контексте ссылающейся таблицы. Знать его, создавая справочник, невозможно. (Потому, что невозможно заранее знать все сценарии использования справочника, на то он и справочник).
И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.
Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области. Что юзер должен с этой колонкой делать? Она же чисто техническая! И нужна, как правило, для стыковки с другими системами. Но совать её в интерфейс на самом первом (то есть, самом дорогом) месте — извините.
Как-то так.
Re[5]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, vdimas, Вы писали:
V>Да понятно, но в БД тоже имена, типы...
V>А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.
V>Многие такие менеджеры еще позволяют графически конструировать запросы.
Зачем пользователю графически конструировать запросы?
Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы. И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».
Упомянутый выше Access, кстати, такой же. По крайней мере, был. (У меня старая версия). Не успел я создать таблицу, как он ошарашил меня вопросом, не хочу ли я задать ключевые поля для установления связей. Выносить в интерфейс такие вещи для меня выглядит очень странно.
S>>Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа.
V>А современные конструкторы сайтов смотрел?
Их много, и хотя форм-фактор «конструктор сайтов» уже идёт вразрез с идеей того, что я делаю, я буду благодарен (чисто для расширения кругозора) за любые примеры того, как описанную функциональность можно сделать в других местах. Например, какие шаблоны они понимают? Txt, HTML, pdf? Что-то ещё? Какой синтаксис используют для разметки?
V>Ну, кое-какие алгоритмы ему знать надо, из разряда что делает тот или иной "кубик" системы (кнопка, команда, режим, их св-ва, как взаимодействует и т.д.)
Я стараюсь исходить из потребностей. В данном случае, как я вижу, есть потребность иметь по каждой строке (описывающей, например, транзакцию) пригодный для печати отчёт (платёжку, счёт, whatever), доступный прямо из таблицы. Соответственно, так это и представлено в UI: добавление колонки типа «Отчёт», для чего нужно выполнить одно действие (не считая задавания имени колонки): выбрать файл с шаблоном. Но, возможно, я в плену предубеждений и можно сделать то же самое понятнее для юзера.
V>Да, юзверь в таких системах работает с предметно-ориентированной средой, заточенной на решение некоего класса задач, т.е. работает с достаточно высокоуровневыми "алгоритмами" и в тех условиях, что околосистемные вещи "кто-то" за него уже решил.
Возможно, что я ошибаюсь, но как раз «предметная ориентированность» и губит все такие продукты. Выше давали ссылку на менеджер чеков для tax return, экспат в Германию описывает свои с ней приключения.
Предметно-ориентированные среды легче позиционировать, да. (То есть, «предметная ориентированность» вообще не про продукт, а про маркетинг — тот же SharePoint как только не впаривали, и как «веб-портал», и как СКД, и как чёрта в ступе, однако его техническая суть от этого не меняется). Но поскольку сама предметная область — понятие расплывчатое, если слишком углубиться в этом направлении, по ходу пьесы часто оказывается, что (в рамках той же предметной области!) сделано много неуниверсальных предположений, введено много ненужных ограничений и так далее.
Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок. Но вы же знаете, что идеал нам только снится
V>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
V>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
А какой именно идее? Как вы её сформулируете?
Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. Оттого, что он завёрнут в мастер, он не перестанет быть программистским мусором.
Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.
По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс. И на передний план выходят вопросы, странные для программиста, но очевидные для юзера, например, сохранять ли форматирование при подстановке, если да — от какого представления (если, конечно, в UI вообще есть представления).
Репрезентативное поле, в отличие от ключевого, для пользователя имеет смысл только в контексте ссылающейся таблицы. Знать его, создавая справочник, невозможно. (Потому, что невозможно заранее знать все сценарии использования справочника, на то он и справочник).
И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.
Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области. Что юзер должен с этой колонкой делать? Она же чисто техническая! И нужна, как правило, для стыковки с другими системами. Но совать её в интерфейс на самом первом (то есть, самом дорогом) месте — извините.
Как-то так.
V>Да понятно, но в БД тоже имена, типы...
V>А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.
V>Многие такие менеджеры еще позволяют графически конструировать запросы.
Зачем пользователю графически конструировать запросы?
Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы. И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».
Упомянутый выше Access, кстати, такой же. По крайней мере, был. (У меня старая версия). Не успел я создать таблицу, как он ошарашил меня вопросом, не хочу ли я задать ключевые поля для установления связей. Выносить в интерфейс такие вещи для меня выглядит очень странно.
S>>Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа.
V>А современные конструкторы сайтов смотрел?
Их много, и хотя форм-фактор «конструктор сайтов» уже идёт вразрез с идеей того, что я делаю, я буду благодарен (чисто для расширения кругозора) за любые примеры того, как описанную функциональность можно сделать в других местах. Например, какие шаблоны они понимают? Txt, HTML, pdf? Что-то ещё? Какой синтаксис используют для разметки?
V>Ну, кое-какие алгоритмы ему знать надо, из разряда что делает тот или иной "кубик" системы (кнопка, команда, режим, их св-ва, как взаимодействует и т.д.)
Я стараюсь исходить из потребностей. В данном случае, как я вижу, есть потребность иметь по каждой строке (описывающей, например, транзакцию) пригодный для печати отчёт (платёжку, счёт, whatever), доступный прямо из таблицы. Соответственно, так это и представлено в UI: добавление колонки типа «Отчёт», для чего нужно выполнить одно действие (не считая задавания имени колонки): выбрать файл с шаблоном. Но, возможно, я в плену предубеждений и можно сделать то же самое понятнее для юзера.
V>Да, юзверь в таких системах работает с предметно-ориентированной средой, заточенной на решение некоего класса задач, т.е. работает с достаточно высокоуровневыми "алгоритмами" и в тех условиях, что околосистемные вещи "кто-то" за него уже решил.
Возможно, что я ошибаюсь, но как раз «предметная ориентированность» и губит все такие продукты. Выше давали ссылку на менеджер чеков для tax return, экспат в Германию описывает свои с ней приключения.
Предметно-ориентированные среды легче позиционировать, да. (То есть, «предметная ориентированность» вообще не про продукт, а про маркетинг — тот же SharePoint как только не впаривали, и как «веб-портал», и как СКД, и как чёрта в ступе, однако его техническая суть от этого не меняется). Но поскольку сама предметная область — понятие расплывчатое, если слишком углубиться в этом направлении, по ходу пьесы часто оказывается, что (в рамках той же предметной области!) сделано много неуниверсальных предположений, введено много ненужных ограничений и так далее.
Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок. Но вы же знаете, что идеал нам только снится
V>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
V>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
А какой именно идее? Как вы её сформулируете?
Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. Оттого, что он завёрнут в мастер, он не перестанет быть программистским мусором.
Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.
По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс. И на передний план выходят вопросы, странные для программиста, но очевидные для юзера, например, сохранять ли форматирование при подстановке, если да — от какого представления (если, конечно, в UI вообще есть представления).
Репрезентативное поле, в отличие от ключевого, для пользователя имеет смысл только в контексте ссылающейся таблицы. Знать его, создавая справочник, невозможно. (Потому, что невозможно заранее знать все сценарии использования справочника, на то он и справочник).
И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.
Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области. Что юзер должен с этой колонкой делать? Она же чисто техническая! И нужна, как правило, для стыковки с другими системами. Но совать её в интерфейс на самом первом (то есть, самом дорогом) месте — извините.
Как-то так.