Мне известно об использовании пространства временных таблиц, это не так далеко, насколько я понимаю, проблема
Напротив - это довольно большая проблема - и есть много другихи недостатки тоже.
Когда вы используете временные таблицы (по крайней мере, в SQL Server), каждая операция UPDATE (даже если данные неизменны) приводит к тому, что копия копируется в таблицу истории (предоставляется, недооценивается). Это может быть копия, оптимизированная для COW, но это еще один экземпляр концептуальной сущности).
Во-вторых, из моего личного опыта работы с приложениями LoB: большинство изменений в базах данных не настолько важны, чтобы оправдать созданиенапример, полную копию строки, представьте таблицу с 4 столбцами (CREATE TABLE People ( FirstName nvarchar(50), LastName nvarchar(50), Address nvarchar(200), Biography nvarchar(max): если опечатка в FirstName исправлена, то копируются все данные в других столбцах, даже если Biography содержитТекстовые данные объемом 4 ГБ - даже если они оптимизированы для COW, они по-прежнему создают копии для каждого действия пользователя, которое приводит к изменению.
По какой причине я не должен просто делать все таблицы временными?
Основная причина, по моему опыту, заключается в том, что это значительно усложняет изменение схемы таблиц, поскольку схемы (то есть "дизайн таблицы")таблиц Active и History должны быть идентичны: так что если у вас есть таблица со столбцом NULL, которую вы хотите изменить на столбец NOT NULL, и у вас есть значения NULL в таблице History, то вы застряли -по крайней мере, до тех пор, пока вы не напишите шаг преобразования данных, который будет снабжать таблицу History действительными данными - это в основном создаст для вас больше работы с небольшим выигрышем.
Кроме того, не путайте Temporal Tables с Immutable, Append-только хранилища данных (например, Биткойн-блокчейн) - хотя они имеют сходные цели проектирования (за исключением истинной неизменности), они существуют для решения разных задач - и если учесть требования к размеру и проблемы масштабирования цепочки блоков Эфириума (более терабайтасейчас) тогда это должно дать вам еще одну идею, почему это, вероятно, не липкаяИдея.
Наконец, даже если у Temporal Tables не было этих проблем - вам все равно нужно приложить усилия для написания вашего основного программного обеспечения так, чтобы оно могло изначально обрабатывать временные данные - и такие вещи, как Entity Framework, по-прежнемуу вас нет встроенной поддержки запросов временных данных.
... и даже со всеми историческими записями, которые вам удалось сохранить в таблице истории, для чего вам это нужно? Вам действительно нужно отследить каждую исправленную опечатку и небольшие несущественные изменения? Как ваши пользователи будут реагировать на необходимость вручную проверять изменения, чтобы определить, что они значат или нет?
Короче говоря:
- Если ваш дизайн таблицы, вероятно, не сильно изменится в будущем...
- И небольшие обновления происходят нечасто ...
- ИЛИ большие обновления происходят регулярно И вам нужна запись аудита
- ... затем продолжайте и используйте временные таблицывезде, где вы можете.
- , если нет, то вы просто создаете для себя больше будущей работы с небольшим выигрышем.