Я думаю, что это субъективный ответ, но я бы оставил систему справочной службы в качестве отдельного объекта, если только нет веских коммерческих причин использовать ту же базу пользователей.
Это в основном основано на том, что я видел в профессиональном программном обеспечении регистрации вызовов / тикетов, но у меня есть еще одна веская причина - безопасность - логика следующая:
Как правило, билетной системе службы поддержки обычно требуется менее конфиденциальная информация, чем в другой бизнес-системе (бухгалтерия, покупки, CRM и т. Д.). Вашим техническим специалистам, вероятно, потребуется знать, как связаться с клиентом, но, вероятно, не потребуется хранить полные адреса, даты рождения и т. Д. Все последующее основано на предположении - что ваши существующие данные о клиентах содержат конфиденциальные или идентифицирующие личность данные это не понадобится вашей системе продажи билетов.
Принцип 1: Сокращение площади поверхности атаки за счет ограничения хранимых данных. Как правило, я согласен с принципом, что вы должны ТОЛЬКО собирать данные, которые вам абсолютно необходимы. Наличие менее конфиденциальной информации означает меньше, чем злоумышленник может украсть.
Принцип 2: Сокращение площади поверхности за счет минимизации возможностей атаки на существующие конфиденциальные данные. Предполагая, что у вас уже есть большая пользовательская база, и что вы уже храните потенциально полезные данные о своих клиентах, добавление еще одного приложения с хуками в эти данные просто добавляет дополнительные возможности для атаки на существующую клиентскую базу. Это приводит меня к ...
Принцип 3: Наименее привилегия. Пользователь, которого вы настроили для базы данных программного обеспечения службы поддержки, должен иметь доступ ТОЛЬКО к тем данным, которые абсолютно необходимы вашим аналитикам службы поддержки. Достигнуть этого легче, если вы разрабатываете свою базу данных с учетом конкретного набора потребностей. С точки зрения обслуживания гораздо сложнее настроить представления и хранимые процедуры для конфиденциальных данных, чтобы разрешить доступ только к нечувствительным данным, чем создать базу данных, в которой есть только те данные, которые вам нужны.
Конечно, я, может быть, слишком обдумываю это. И есть другие веские причины для того, чтобы идти по любому пути. Я просто пытаюсь дать вам кое-что, о чем подумать.