Первичные ключи, UUID, таблицы RecordKey, о боже

Question

Работая над системой управления контентом, я наткнулся на стену.Возвращаясь к моей модели данных, я заметил некоторые проблемы, которые могут стать более распространенными со временем.

А именно, я хочу вести контрольный журнал (журнал изменений) изменений записей пользователем (даже изменений записей пользователей)будет зарегистрирован).Из-за включения произвольного числа модулей я не могу использовать поле автоинкрементации таблиц для своих первичных ключей, так как оно неизбежно вызовет конфликты при попытке сохранить их ключи в одной таблице.

В журнале аудита будут храниться записи user_id, record_id, timestamp, action (INSERT / UPDATE / DELETE) и archive (сериализованная копия старой записи)

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

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

В конечном счете, мне любопытно узнать, какие варианты я должен рассмотреть, пытаясь реализовать это.Например, я намереваюсь разрешить (хотя бы запустить) параметры хранилища MySQL и SQLite3, но меня беспокоит то, как каждая база данных будет обрабатывать UUID s.

Edit, чтобы сделать мой вопрос менее расплывчатым: Будет ли использование глобальных идентификаторов рекомендуемым решением для моей проблемы?Если это так, используя 128-битный UUID (приложение или сгенерированная база данных), что я могу сделать в моей схеме таблицы, которая поможет максимизировать эффективность запросов?

Answer 1

Хорошо, вы попали в кирпичную стену. И вы понимаете, что на самом деле дизайн БД имеет проблемы. И вы будете продолжать бить эту самую кирпичную стену много раз в будущем. И твое будущее не выглядит светлым. И вы хотите изменить это. Хорошо.

Но то, что вы еще не сделали, это выясните, какова истинная причина этого. Вы не можете сбежать из предсказуемого будущего, пока не сделаете это. И если вы сделаете это правильно, то не будет кирпичной стены, по крайней мере, этой конкретной кирпичной стены.

Во-первых, вы пошли и вставили Id iot столбцы во все таблицы, чтобы добиться уникальности, не понимая по-настоящему идентификаторов и ключей, которые обычно использовались для поиска данных. Это кирпичи, из которых сделана стена. Это была непредсказуемая реакция коленного рефлекса на проблему, которая требовала рассмотрения. Это то, что вам придется повторно посетить.

1. Не повторяйте ту же ошибку снова. Удаление GUID, UUID или 32-байтовых Id iot-столбцов для исправления ваших NUMERIC(10,0) Id iot-столбцов ничего не изменит, за исключением того, что делает db намного толще, а все обращения , особенно соединения, намного медленнее. Стена будет сделана из бетонных блоков и будет бить вас каждый час.

2. Вернитесь и посмотрите на таблицы и спроектируйте их так, чтобы они были таблицами в базе данных. Это означает, что ваша отправная точка - Без суррогатных ключей , без Id в столбцах. Когда вы закончите, у вас будет очень мало Id столбцов. Не ноль, не все таблицы, но очень мало. Поэтому у вас очень мало кирпичей в стене. Недавно я опубликовал подробный набор необходимых шагов, поэтому, пожалуйста, обратитесь к:

   Ссылка на ответ по идентификаторам

3. Каково оправдание наличия одной контрольной таблицы, содержащей контрольные «записи» всех таблиц? Вам нравится встречаться с кирпичными стенами? Вы хотите, чтобы параллелизм и скорость базы данных были узкими местами в горячей точке вставки в одном файле?

   Требования к аудиту внедряются в dbs более 40 лет, поэтому вероятность того, что у ваших пользователей будет какое-то другое требование , которое не изменится , не очень высока. Можем также сделать это правильно. Единственный правильный метод (для Rdb) для таблиц аудита - это иметь одну таблицу аудита для каждой проверяемой реальной таблицы. PK будет исходной таблицей PK плюс DateTime (составные ключи являются нормальными в современной базе данных). Дополнительные столбцы будут UserId и Action. Сама строка будет предыдущим изображением (новое изображение является единственной текущей строкой в ​​основной таблице). Используйте точно такие же имена столбцов. Не упаковывайте его в одну гигантскую строку.

   Если вам не нужны данные (перед изображением), тогда прекратите запись . Очень глупо записывать всю эту громкость без всякой причины. Восстановление можно получить из резервных копий.

4. Да, одна таблица RecordKey - это чудовище. И еще один гарантированный метод однопоточности базы данных.

Не реагируйте на мой пост, я уже вижу по вашим комментариям, что у вас есть все "правильные" причины для того, чтобы поступать неправильно и держать кирпичные стены в целости и сохранности. Я пытаюсь помочь вам уничтожить их. Обдумайте это несколько дней, прежде чем отвечать.

Answer 2

Более эффективная схема - создать таблицу аудита, которая отражает структуру каждой таблицы, а не помещать весь журнал аудита в одно место. Модель «теневой» таблицы упрощает запрос контрольного журнала.

Answer 3

Как насчет сохранения всех record_id локально для каждой таблицы и добавления еще одного столбца table_name (в таблицу аудита) для составного ключа?

Таким образом, вы также можете легко отфильтровать журнал аудита по table_name (что будет непросто с произвольным UUID или порядковыми номерами). Поэтому, даже если вы не согласны с этим решением, рассмотрите возможность добавления столбца table_name в любом случае, чтобы запросить журнал позже.

Чтобы поместить record_id из всех таблиц в один и тот же столбец, вам все равно необходимо обеспечить, чтобы все таблицы использовали одинаковые типы данных для своих идентификаторов (но, похоже, вы все равно планировали это сделать).