我的应用程序管理客户的投诉并已部署到生产。每个投诉都有一个代码来识别它（用于简化“延迟交付”），一个“部门”类型（主要是负责此类投诉的部门）和另一个“模型”代码，用于识别通过部门员工的投诉路线档案必须遵循（首先到hr负责然后到hr大老板最后回到客户关怀）。每个档案都有一些共同的信息，可以有部门特定的信息，这就是我需要代码的原因。 例如，客户服务部门会对呼叫中心运营商的“粗鲁”进行投诉，打开一个代码为ABC的档案并输入“HR”（可能会有更多HR档案类型）。当客户服务已填满所有信息时，将其转发至hr（邮件将发送给系统中配置为HR负责的用户）。 hr员工填写自己的部分并将其发回客户服务部门。
到目前为止，每个投诉代码可能只有一个部门和一个模型，现在需求已经改变，我有两个问题：
我可以解决这个问题，只需将表主键扩展到包含部门（希望他们不会为同一个部门决定相同的代码可以遵循不同的路由），更改应用程序代码可能会有点痛苦但是可以做到：
将主键扩展到组合键是Oracle中的问题还是对现有记录有副作用？实际的主键不会被用作外键，而且所有字段都被填充。
我知道很难在不能看到架构和代码的情况下发表意见，但无论如何我会很感激你的意见
答案 0 :(得分：1)
“将主键扩展到 复合键是Oracle中的一个问题 或对现有有副作用 记录？实际的主键不是 任何一切都被用作外键 字段已填满。“
Oracle允许我们拥有复合主键。从关系角度来看，它们不是问题。
对主要复合键的唯一反对是通常的，它们使外键关系和连接更加麻烦。你说你目前没有引用该表的外键。不过，我建议您使用索引定义合成（代理）主键，并将复合键强制作为唯一约束。因为将来可能会有外键：您的困境表明您当前的数据模型不正确，或者至少不完整。
“我可以为每个人添加新记录 投诉代码有第二部分 关键是营销代码“
智能钥匙很笨。如有必要，为营销代码添加单独的列。如果市场营销开放他们自己的档案，这将填充。我不明白为什么它需要与Complaint Code相关联或构成任何主键的一部分（营销代码查找表除外）。
我承认我并不完全了解您的数据模型或业务逻辑，因此以下内容可能有误。但是我认为你想要的是一个DOSSIERS表，它可以有两种档案类型：
唯一约束允许NULL列，因此MARKETING_CODE可以是可选的。这是使用一个而不是复合主键的另一个优点。
“我觉得它很容易出错 插入新的投诉代码。“
你的意思是创造新的投诉吗？还是新的投诉类型？创建新投诉应该不是问题：创建普通档案的过程将提供COMPLAINT_CODES选项，其中MARKETING_CODE为空，而创建营销档案的过程将提供COMPLAINT_CODES选项，其中MARKETING_CODE不为空。
如果您正在谈论添加新投诉类型，那么我想问题就变成了：每个常规COMPLAINT_CODE是否必须有单独的MARKETING_CODE？我怀疑不是。在这种情况下，您可能需要CODE_TYPE - 值NORMAL或MARKETING而不是MARKETING_CODE。