рефакторинг базы данных и приложения в связи с новыми требованиями

Question

Мое приложение обрабатывает жалобы клиентов и уже развернуто в производство .У каждой жалобы есть код для ее идентификации (например, «поздняя доставка»), тип «отдела» (который по сути является отделом, ответственным за такого рода жалобы) и другой «модельный» код, который идентифицирует маршрут через сотрудников департамента по этой жалобе.Должно последовать досье (сначала на ответственного сотрудника, затем на большого босса, наконец, на службу поддержки клиентов).Каждое досье имеет некоторую общую информацию и может содержать конкретную информацию о департаменте, поэтому мне нужен код отдела.Например, служба поддержки клиентов получает жалобу на «грубость» оператора колл-центра, открывает досье с кодом ABC и типом «HR» (может быть больше типов досье HR).Когда служба поддержки клиентов заполнила всю информацию, перешлите ее на hr (письмо отправляется пользователю, настроенному в системе как ответственный за работу с персоналом).Сотрудник отдела кадров заполняет свой собственный раздел и отправляет его обратно в службу поддержки.

До сих пор каждый код жалобы мог иметь только один отдел и одну модель, теперь требования изменились, и у меня две проблемы:

1. Некоторые жалобы идентифицируются одним и тем же кодом, но могут быть связаны с разными отделами.Например, жалоба на грубость сотрудников может быть отправлена ​​в отдел, который управляет центрами обработки вызовов, или в отдел, который управляет логистикой

. Я мог бы решить эту проблему, просто расширив первичный ключ таблицы, включив в него отдел (надеясь, чтоони не решат, что один и тот же код для одного и того же отдела может следовать по разным маршрутам), изменение кода приложения может быть немного болезненным, но это можно сделать:

Не является ли расширение первичных ключей составными ключами проблемой в Oracleили имеют побочные эффекты на существующие записи?фактический первичный ключ больше не используется в качестве внешнего ключа, и все поля заполнены.

1. это более сложная проблема (по крайней мере, для меня): отдел маркетинга (правители) хочет специальное досьеОни следят за тем, чтобы департаменты отвечали на жалобы и открывали досье нового типа, если они превышают стандартное время.В приведенном выше примере, если hr всегда требуется на 30% больше времени для заполнения досье о хамстве сотрудников, отдел маркетинга может открыть досье «справки» о коде жалобы, направленном на hr.
   Теперь, ссылаясь на пункт 1, я мог бы добавитьновая запись для каждого кода жалобы, имеющая вторую часть ключа, являющуюся маркетинговым кодом, и связывающую его с новой моделью. Это приведет к удвоению строк таблицы (которая уже достаточно велика).Я вижу, что это очень подвержено ошибкам при вставке новых кодов жалоб.

Я знаю, что очень трудно высказать мнение, не имея возможности увидеть схему и код, но я все равно был бы признателен за ваше мнение

Answer 1

"Является ли расширение первичных ключей составными ключами проблемой в Oracle или имеет побочные эффекты для существующих записей? Фактический первичный ключ не используется в качестве внешнего ключа, и все поля заполнены."

Oracle позволяет нам иметь составные первичные ключи.Они не являются проблемой с точки зрения отношений.

Единственное возражение против первичных составных ключей - это обычное возражение, заключающееся в том, что они делают отношения внешнего ключа и объединяют более громоздкими.Вы говорите, что в настоящее время у вас нет внешних ключей, которые ссылаются на эту таблицу.Тем не менее, я бы предложил вам определить синтетический (суррогатный) первичный ключ, используя индекс, и использовать составной ключ как уникальное ограничение.Потому что в будущем у вас вполне могут быть внешние ключи: ваше затруднительное положение показывает, что ваша текущая модель данных неверна или, по крайней мере, неполна.

«Я мог бы добавить новую запись для каждого кода жалобы, имеющего вторую часть ключа, являющуюся маркетинговым кодом» *

Умные клавиши тупые.При необходимости добавьте отдельный столбец для маркетингового кода.Это будет заполнено, если Маркетинг откроет свое собственное досье.Я не понимаю, почему его нужно связывать с кодом жалобы или составлять часть какого-либо первичного ключа (кроме таблицы поиска маркетингового кода).

Я признаю, что не полностью понимаю вашу модель данных илибизнес-логика, поэтому следующее может быть неправильно.Однако я думаю, что вам нужна таблица DOSSIERS, которая может иметь два типа досье:

• нормальное досье, идентифицированное с помощью DEPT_CODE и COMPLAINT_CODE
• Маркетинговое досье, которое, как я предполагаю, будет определено с помощью DEPT_CODE,COMPLAINT_CODE и MARKETING_CODE.

Уникальные ограничения допускают столбцы NULL, поэтому MARKETING_CODE может быть необязательным.Это еще одно преимущество использования одного вместо составного первичного ключа.

«Мне кажется, что при вводе новых кодов жалоб это может привести к ошибкам».

Вы имеете в виду создание новых жалоб?Или новые типы жалоб?Создание новых жалоб не должно быть проблемой: процесс создания обычных досье будет предлагать выбор COMPLAINT_CODES, где MARKETING_CODE равен нулю, тогда как процесс создания маркетинговых досье будет предлагать выбор COMPLAINT_CODES, где MARKETING_CODE не равен нулю.

Если вы говорите о добавлении новых типов жалоб, то я полагаю, что возникает вопрос: должен ли быть отдельный MARKETING_CODE для каждого обычного COMPLAINT_CODE?Я подозреваю, что нет.В этом случае вместо MARKETING_CODE, возможно, вам потребуется CODE_TYPE - значения NORMAL или MARKETING.