为什么不基于数据库模式构建UI？

Question

人们似乎避免构建从数据库中提取信息(名称,字段类型等以及关系)的用户界面; 他们反而硬编码具有几乎相同的数据名称和类型和事物的表单(和表格等).

我有道理吗？

例如,想象一下MySQL中的一个数字字段:为什么不让UI在遇到ENUM时构建一个下拉列表？为什么在数据库和代码中都放置相同的值？

也许我只是遗漏了一些东西; 也许有些项目可以做到这一点 - 可以指向任何数据库的超级crud接口,并从中构建一个功能齐全的关系感知用户界面.在那儿？

我可能不太符合这个问题的stackoverflow规范; 我将总结一下:

1. 您能告诉我一个项目,它(仅)通过分析数据库模式构建其用户界面吗？
2. 为什么这不是一种常用的方法 - 当然只在一个地方(即数据库)定义数据结构是好的？

谢谢你,并且可能会喜欢在你的IDE上爱上雨.

Answer 1

我想指出的是,上次我检查时,.NET和Qt(以及可能还有其他环境)可以使用"数据库感知小部件"(有时简称为数据感知小部件),这可能是最好的实用解决方案.数据感知小部件的意思是小部件本身知道它们直接链接到数据库字段,因此您将拥有一个组合框,它知道它由枚举支持并在运行时直接从数据库中获取可能的值,就像你建议的那样.

这是一个非常简洁的实用程序,使用得很好,它可能不会伤害任何东西.它仍然需要您花一些时间在表单上手动布局窗口小部件,但是如果您更新数据库以向该枚举添加新值,则不必重新构建应用程序以使其显示在UI中.

但是大多数可用性专家在听到你的问题时会畏缩的原因是因为程序员倾向于认为,为什么不从数据库生成整个 UI,表单布局和所有内容？这就是它开始变得非常讨厌,非常快的地方.

假设你有一个简单的Person表,包括first_name,last_name,email_address,street_address,city,state,zip和phone_number.您希望根据这些字段自动生成UI.你如何对田地进行排序？我的意思是,理想情况下,名字和姓氏应该紧挨着.如果你在街道地址之前有城市和州,那就太傻了.因此,您必须向表中添加新列以指定排序顺序(如果您使用最快的方法),或者添加新表以指定每个字段的字段ID的顺序索引.

如果您想单独分组部分信息怎么办？然后,您必须在数据库布局中添加更多特定于UI的cruft(为了做到这一点,您需要一个新表来指定哪些UI字段属于哪些UI组框).所以你只解决了两个问题并且你的数据库布局已经变得丑陋了两倍,加上现在加上UI后你不必进行简单的O(1)布局操作,你必须做几个数据库查询来找出哪些字段存在并在应用正确的小部件顺序时动态布局它们...我们甚至没有处理大小调整(每个字段应该是最大尺寸以适合其可能的内容,还是所有文本字段都应该是相同的宽度？不会'如果你可以说一些文本字段应该是一个宽度和高度,而另一些应该是另一种组合？等),或者文本对齐,或格式化,或任何其他真正常见的基本可用性要求,需要进一步牺牲,这是很好的数据库架构的清晰度和简单性.

Answer 2

1. 大多数可视化数据库编辑器。例如phpMyAdmin 。

2. 因为数据库结构并不总是供用户使用的非常好的逻辑结构，特别是在出于效率原因而故意非规范化的数据库的情况下。