获取所有仍然打开的帖子
"SELECT * FROM posts WHERE status_id = (SELECT id FROM statuses WHERE name = 'open')"
通常情况下,查找表本身很短.例如,可能只有3个左右的不同状态.在这种情况下,是否可以在应用程序中使用常量来搜索某种类型？就像是
获取所有仍然打开的帖子
"SELECT * FROM posts WHERE status_id = ".Status::OPEN
或者,如果不是使用外部id,我将其设置为枚举并查询？
谢谢.
解决方法
在真正的数据库中,有许多应用程序使用一个数据库,许多用户使用不同的报表工具(而不仅仅是应用程序)访问数据,标准,规范化和开放架构要求很重要.
尽管人们试图改变“规范化”的定义等来达到目的,但是规范化没有改变.
>如果在数据表中重复“打开”和“关闭”,那就是一个简单的规范化错误.如果您更改这些值,您可能必须更新数百万行,这是非常有限的设计.这些值通常被归一化为参考或查找表.它也节省空间.值“Open”,“Closed”等不再重复.
>第二点是易变性,如果“已关闭”更改为“已过期”,则需要更改一行,这反映在整个数据库中;而在非标准化文件中,需要更改数百万行.
>添加新值只是一个插入一行的问题.
>在Open Architecture术语中,Lookup表是一个普通表.它存在于(标准sql)目录中;任何报表工具都可以找到它,只要定义了PK :: FK关系,报表工具就可以找到.
>枚举仅适用于非sqlS.在sql中,枚举是一个查找表.
>下一个关键点与钥匙的意义相关.如果密钥对用户无意义,则可以使用INT或TINYINT或任何适合的密钥;递增编号允许“差距”.但是如果Key对用户有意义,不要使用无意义的数字,请使用有意义的键.男,女“M”,“F”等
>现在有些人会进入切线,这是永久性的PK.这是一个单独的点.是的,当然,总是使用稳定的PK值. “M”和“F”不太可能改变;如果你使用{0,1,2,4,5,6},那么不要改变它,你为什么要这样做.这些价值观应该是无意义的,只有意义的关键需要改变.
.
>如果您使用有意义的键,请使用短字母代码,用户和开发人员都可以轻松了解(并从中推断长期描述).
>由于PKs稳定,特别是在Lookup表中,您可以安全地编码：
WHERE status_id =’O’
您不必与查找表一起查看值“打开”.这会在代码段中丢失查找表的值.
sql是一种麻烦的语言,尤其是在连接时.但是这就是我们所有的,所以我们只需要接受产权负担并处理它.你的示例代码很好.但更简单的形式可以做同样的事情.报表工具会产生：
SELECT p.*,s.name
FROM posts p,status s
WHERE p.status_id = s.status_id
AND p.status_id = 'O'
>对于银行系统,我们使用有意义的短代码(因为它们是有意义的,我们不会随季节而改变),给定一个查找表,如(仔细选择,类似于ISO国家代码)：
Eq Equity EqCS Equity/Common Share O Over The Counter OF OTC/Future
这样的代码是常见的：
WHERE InstrumentTypeCode LIKE“Eq％”
并且用户将从显示“打开”,“关闭”等的下拉列表中选择不是{0,6}而不是{M,F,U}的值.在应用程序和报表工具中.没有查找表,你不能这样做.
最后,如果数据库很大,并且支持BI或DSS或OLAP函数(高度归一化数据库),那么查找表实际上就是Dimension-Vector中的Dimension或Vector.如果不存在,则必须添加,才能满足该软件的要求,然后才能安装此类分析.
