我的应用程序管理客户投诉，并且已经部署到生产。每个投诉都有一个代码来识别它(例如"延迟交货")，一个"部门"类型(本质上是负责这种投诉的部门)和另一个"模型"代码，该代码标识该投诉档案必须遵循的部门员工路线(首先到hr负责人，然后到hr大老板，最后回到客户服务)。每个档案都有一些共同的信息，可以有部门特定的信息，这就是为什么我需要部门代码。例如，客服收到一个关于呼叫中心接线员"粗鲁无礼"的投诉，打开一个代码为ABC的档案，输入"HR"(可能有更多的HR档案类型)。当客户服务填写完所有信息后，将其转发给hr(将邮件发送给系统中配置为hr负责人的用户)。人力资源部门的员工填写自己的表格，并将其发回客户服务部。
到目前为止，每个投诉代码可能只有一个部门和一个模型，现在需求发生了变化，我有两个问题:
- 一些投诉由相同的代码识别，但可能是由于不同的部门。例如，关于员工粗鲁行为的投诉可以发送到负责呼叫中心的部门或负责物流的部门
我可以简单地扩展表的主键来包含部门(希望他们不会决定相同部门的相同代码可以遵循不同的路由)，更改应用程序代码可能有点痛苦，但它可以做到:
扩展主键到复合键在Oracle中是一个问题还是对现有记录有副作用?实际的主键不在任何地方用作外键，并且所有字段都被填充。
- 这是一个相当困难的问题(至少对我来说):市场部门(统治者)想要一个特殊的档案。他们会监控部门处理投诉的时间，如果超过标准时间，就会建立一个新的档案。对于上面的例子，如果hr总是需要30%以上的时间来完成员工无礼档案，那么营销部门可以打开一个"查询"档案，将投诉代码直接发送给hr。
现在，参照第1点，我可以为每个投诉代码添加一个新记录，其中密钥的第二部分是营销代码，并将其关联到一个新模型。这将使表的行数增加一倍(它已经相当大了)。我认为插入新的投诉代码非常容易出错。
我知道在没有看到模式和代码的情况下很难给出意见，但我还是希望你能给出意见
"将主键扩展到复合键是Oracle中的一个问题或者对现有产品有副作用记录?实际的主键不是用作任何地方的外键字段被填充。"
Oracle允许我们有复合主键。从关系的角度来看，它们不是问题。
对主组合键的唯一反对是通常的，即它们使外键关系和连接更加麻烦。你说你目前没有引用这个表的外键。尽管如此，我还是建议您使用索引定义合成(代理)主键，并将组合键强制为唯一约束。因为您将来很可能会有外键:您的困境表明您当前的数据模型不正确，或者至少不完整。
"我可以为每个人添加一个新记录投诉代码包含第二部分关键是营销代码"
智能钥匙是哑的。如果有必要，为营销代码添加一个单独的列。如果市场营销部门打开他们自己的档案，这将会被填充。我不明白为什么它需要与投诉代码相关联，或者构成任何主键的一部分(除了营销代码查找表)。
我承认我不完全理解您的数据模型或业务逻辑，因此下面的内容可能是错误的。然而，我认为你需要的是一个表DOSSIERS，它可以有两种档案类型:
- 由DEPT_CODE和COMPLAINT_CODE标识的正常档案
- 营销档案，我认为将由DEPT_CODE，投诉代码和MARKETING_CODE识别。
唯一约束允许NULL列，因此MARKETING_CODE可以是可选的。这是使用单一主键而不是复合主键的另一个优点。
你的意思是制造新的抱怨吗?或者新的投诉类型?创建新的投诉不应该是一个问题:创建普通档案的过程将提供一个投诉代码的选择，其中MARKETING_CODE为空，而创建营销档案的过程将提供一个投诉代码的选择，其中MARKETING_CODE不为空。"我认为它很容易出错。插入新的投诉代码。"
如果你在谈论添加新的投诉类型，那么我想问题就变成了:是否必须为每个常规的投诉代码设置一个单独的MARKETING_CODE ?我不这么认为。在这种情况下，您可能需要一个CODE_TYPE值为NORMAL或MARKETING，而不是MARKETING_CODE。