gpt4 book ai didi

sql - 使用 JOIN 来避免数字 ID 是一件坏事吗?

转载 作者:行者123 更新时间:2023-12-02 04:36:16 24 4
gpt4 key购买 nike

<分区>

昨天我在看这样的查询:

SELECT <some fields>
FROM Thing
WHERE thing_type_id = 4

...并且不得不认为这是非常“可读的”。什么是“4”?这是什么意思?我以前在编码语言中做过同样的事情,但现在我会为此使用常量,将 4 变成 THING_TYPE_AVAILABLE 或类似的名称。没有没有意义的神秘数字了!

I asked about this on here并获得有关如何在 SQL 中实现此目的的答案。

我主要偏向于将 JOINS 与现有类型表一起使用,其中您有一个 ID 和一个代码,当没有此类表时可能会使用其他解决方案(并非每个数据库都是完美的......)

SELECT thing_id
FROM Thing
JOIN ThingType USING (thing_type_id)
WHERE thing_type_code IN ('OPENED', 'ONHOLD')

所以我开始在一两个查询中使用它,我的同事很快就对我说:“嘿,你在查询中有文字代码!” “嗯,你知道,我们通常为此选择 pk”。

虽然我能理解这种方法不是通常的方法(嘿,直到现在我也不适合我),但真的有那么糟糕吗?

这样做的优缺点是什么?我的主要目标是可读性,但我担心性能,想确认这个想法是否合理。

编辑:请注意,我不是在谈论 PL/SQL,而是直接查询,通常以 SELECT 开头的那种。

编辑 2:为了进一步阐明我用虚假(但结构相似)示例的情况,这里是我的表格:

Thing
------------------------------------------
thing_id | <attributes...> | thing_type_id
1 3
4 7
5 3

ThingType
--------------------------------------------------
thing_type_id | thing_type_code | <attributes...>
3 'TYPE_C'
5 'TYPE_E'
7 'TYPE_G'

thing_type_code 与 thing_type_id 一样独特。它目前还用作显示字符串,我认为这是一个错误,但现在可以通过添加复制 thing_type_code 的 thing_type_label 字段轻松修复,并且可以在以后需要时随时更改。

据推测,使用 thing_type_code = 'TYPE_C' 进行过滤,我肯定会得到恰好是 thing_type_id = 3 的那一行。联接仍然可以(而且很可能应该)使用数字 ID 完成。

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com