Я хотел бы отметить, что в прошлый раз, когда я проверял, .NET и Qt (и, возможно, другие среды) позволяют использовать «виджеты с поддержкой базы данных» (иногда сокращенные до просто виджетов с поддержкой данных), которые это, вероятно, лучшее прагматическое решение. Под виджетами, учитывающими данные, я подразумеваю, что сами виджеты знают, что они связаны непосредственно с полями базы данных, поэтому у вас будет комбинированный список, который знает, что он поддерживается перечислением, и получает возможные значения непосредственно из базы данных во время выполнения, как ты и предлагал.
Это действительно аккуратная утилита, и она хорошо используется, и, вероятно, ничего не повредит. Это все еще требует, чтобы вы потратили некоторое время на размещение виджетов вручную на форме, но затем, если вы обновите базу данных, чтобы добавить новое значение к этому перечислению, вам не нужно перестраивать приложение, чтобы увидеть его в пользовательском интерфейсе.
Но причина, по которой большинство экспертов по юзабилити смущается, услышав ваш вопрос, заключается в том, что программисты склонны думать, что, ну почему бы просто не сгенерировать весь пользовательский интерфейс, макет формы и все остальное из базы данных? И вот тут-то и начинает становиться очень противно, очень быстро.
Допустим, у вас есть простая таблица Person, в которой указаны имя, фамилия, адрес электронной почты, адрес улицы, город, штат, почтовый индекс и номер телефона. Вы хотите автоматически генерировать пользовательский интерфейс на основе этих полей. Как вы сортируете поля? Я имею в виду, в идеале, имя и фамилия должны быть рядом друг с другом. И это было бы очень глупо, если бы вы указали город и штат до адреса улицы. Поэтому вам нужно добавить новый столбец в таблицу, чтобы указать порядок сортировки, если вы используете самый быстрый метод, или новую таблицу, чтобы указать индекс порядка каждого поля для их идентификатора поля.
Что если вы хотите сгруппировать части информации отдельно? Затем вам нужно добавить больше UI-специфических элементов в макет вашей базы данных (чтобы сделать это в общем, вам понадобится новая таблица, указывающая, какие поля UI принадлежат каким групповым полям UI). Таким образом, вы решили только две проблемы, и уже ваш макет базы данных стал в два раза хуже, плюс теперь вместо простой операции макета O (1) при загрузке пользовательского интерфейса вам нужно выполнить несколько запросов к базе данных, чтобы выяснить, какие поля существуют и динамически размещают их при применении правильного порядка виджетов ... и мы даже не имели дело с размером (должен ли каждое поле иметь максимальный размер, чтобы соответствовать его возможному содержимому, или все текстовые поля должны иметь одинаковую ширину? Было бы неплохо, если бы вы могли сказать, что некоторые текстовые поля должны иметь одну ширину и высоту, а некоторые - другую комбинацию? и т. д.), или выравнивание текста, или форматирование, или любые другие действительно общие элементарные требования юзабилити, которые потребуют дополнительных жертв от ясность и простота схемы вашей базы данных.