Впервые я занимаюсь разработкой в среде, в которой есть центральное хранилище для ряда различных стандартных таблиц стандартных данных и множества различных клиентов, которым необходимо выбрать записи из этих стандартных таблиц стандартных данных, чтобы заполнить их. информация о внешнем ключе для их записей о клиентах.
Поскольку эти стандартные отраслевые справочные файлы используются всеми клиентами, я хочу зарезервировать доступ к этим записям для создания, обновления и удаления для глобальных администраторов продукта. Однако я хотел бы реализовать (полу) автоматизированный интерфейс, с помощью которого конкретные клиенты могут запрашивать добавление, удаление или изменение записей в любом из стандартных эталонных файлов, которые являются общими для всех клиентов.
Я знаю, что мне нужно что-то вроде таблицы «запрос на изменение данных» с указанием:
идентификатор пользователя,
пользовательский запрос datetime,
тип запроса (вставить, изменить, удалить),
пользователь ввел текстовое объяснение запроса на изменение,
текущий статус запроса пользователя (ожидающий, отклоненный, выполненный),
администратор дата и время,
идентификатор администратора,
администратор ввел текстовое описание резолюции,
и т.д.
Что я не могу понять, так это как элегантно обрабатывать тот факт, что эти запросы на изменение данных могут применяться к десяткам различных таблиц с разными определениями столбцов таблиц. Я хотел бы предоставить пользователям-клиентам, выполняющим эти запросы на изменение данных, удобный способ ввода предлагаемых дополнений / модификаций записей непосредственно в экраны CRUD, которые очень похожи на экраны справочной таблицы CRUD, для которых у них нет прав на запись / удаление (с дополнительное текстовое объяснение и, возможно, поле запроса приоритета). Я также хотел бы предоставить глобальным администраторам инструмент, который позволяет им просматривать все невыполненные запросы на изменение данных для пользователей, которых они контролируют, отсортированные по запрошенной дате или запрошенному пользователю / дате. После выбора записи запроса на изменение данных из списка администратор будет перенаправлен на другой экран CRUD, который будет заполнен полями, запрошенными пользователями клиента для новой / измененной записи справочной таблицы отраслевого стандарта, а также текстовым объяснением клиента, статусом запроса и поле объяснения разрешения текста. На этом этапе администратор может принять / отредактировать / отклонить запрошенное изменение, и, если он будет принят, соответствующий ссылочный файл отраслевого стандарта будет автоматически обновлен соответствующими полями, и статус записи запроса на изменение данных, пояснение разрешения текста и дата разрешения времени также будут соответствующим образом. обновлен.
Тем не менее, я хочу сохранить фактические производственные справочные таблицы как можно более простыми и свободными от этих посторонних и обычно нулевых полей запроса на изменение клиента. Я также хотел бы, чтобы файл запроса на изменение данных объединял все запросы на изменение данных во всех ссылочных таблицах, но каким-то образом "указывал" на конкретную ссылочную таблицу и первичный ключ, о котором идет речь, для запросов на изменение и удаление или на конкретную справочную таблицу и связанного пользователя-пользователя введенные значения полей для запросов на создание записей.
У кого-нибудь есть идеи, как эффективно спроектировать что-то подобное? Есть ли более простой способ, которого мне не хватает?