我正在尝试加密一列，我发现许多使用 DBMS_CRYPTO 的教程。但是，当我对此进行测试时，它说 DBMS_CRYPTO 是无效标识符。 我使用的是 SYSDBA 帐户。
我在互联网上搜索过，但令我惊讶的是，我找不到这个问题的答案。
为什么 DBMS_CRYPTO 是无效标识符？
我无法通过谷歌搜索找到答案。
我只是听到一个高级开发人员告诉初级开发人员使用 order by 子句对性能有负面影响，他不应该使用它（Oracle）。
在什么情况下 order by 子句会对性能产生负面影响？
更新
我发现由于 ORDER BY 子句导致 SQL 查询性能不佳。是否有其他情况下 order by 条款可能会对性能产生负面影响？
我在一家随机公司担任“访客”开发人员。
我正在处理一个根据定义（Oracle）没有主键的表。
名为“SOMETHING_ID”的列是 varchar2(10) 并在插入时通过以下操作构造。它用作主键并被其他表引用。
'A_STRING' || LPAD(SEQUENCE_NAME.NEXTVAL, 7, '0')
主键数据的一些示例是
CH-00004321
CH-00004322
CH-00004323
我的问题是，
首先，在什么情况下使用由记录类型（比方说，CH 表示中国菜，In 表示印度菜，MX 表示墨西哥菜）和序列号的组合的主键是合理的？
其次，在什么情况下不定义主键但您有一个明确区分每一行的列是合理的？
第三，我的看法是否正确，我看到类型字符串（CH、IN、MX）和序列号的组合违反了第一规范化？
第四，在表中，只有一个“类型字符串”值（假设是 CH）。是否可以将该字符串添加到 pk 而它似乎没有必要，因为只有一个值？（尽管与我的食物示例不同，表格的性质似乎不允许类型字符串的任何其他值。也许您可以将表格名称视为“CHINESE_FOOD”，因此没有其他类型的字符串值似乎合乎逻辑。）
注 - 1. 实际列、序列名称替换为任意名称。
2. 本软件的目的是预测自然灾害造成的损失。
我非常仔细地问过表设计师为什么他选择在多个表中创建 CSV 列。
设计师的回答是，将 CSV 列拆分为单独的表是“不必要的复杂”。
在隐式连接中使用一个 CSV 列来计算 CSV 列中众多值中的一个值已被使用的次数。
where绑定两个表的原因使用了一个like % | table_b.csv_column | %操作。
我阅读并了解到，如果有充分的理由，并不总是需要规范化。
但是，我不知道什么是不正常化的充分理由。
这是（避免“复杂化”）不强制执行第一范式（1NF）的一个很好的理由吗？
桌子： TB_DISASTER_CAUSE_CATE
CATEGORY_ID CATEGORY_N CATEGORY_L L
------------- ---------- ---------- -
DC006001002 **** 3 Y
DC006001003 **** 3 Y
DC006002001 **** 3 Y
DC007001001 **** 3 Y
DC007002001 **** 3 Y
DC007002002 **** 3 Y
DC007003001 **** 3 Y
DC007003002 **** 3 Y
DC007003003 **** 3 Y
桌子： TB_DISASTER_HISTORY
SEQ DISASTER_TYPE DISASTER_CAUSE
----- ------------- ------------------------------------------------------------
32 DT001003002 DC001001004|DC002001002|DC003001001|DC007002001 …normalization database-design best-practices denormalization
在下面的查询中，条件
and r.master_seq=206
在 on 子句上用作连接条件。在程序代码中，值r.master_seq由参数设置。
我担心的是，我不确定将这种条件（r=.master_seq=123，我认为应该是 where 条件）混合到连接条件中是否可以。
我在想我应该只在 join 子句中使用关系信息（主键和外键），而不是 where 条件（ where id=123, balance>300 等）。
SELECT
*
FROM
TB_REQUEST_DATA D
left outer join
TB_SPOT_REPORT_REQUEST r
on D.SEQ = r.REQUEST_SEQ
and r.master_seq=206
WHERE
d.SEQ IN (
7,12,5,11,4
)
desc tb_request_data;
Name Null Type
------------- -------- -------------
SEQ NOT NULL NUMBER
REQUEST_NM NOT NULL VARCHAR2(50)
REG_DT NOT NULL DATE
REG_ID NOT NULL VARCHAR2(20)
UP_DT NOT NULL DATE
UP_ID NOT NULL VARCHAR2(20)
DISASTER_TYPE VARCHAR2(500)
desc TB_SPOT_REPORT_REQUEST;
Name Null …