Имеет ли смысл стандартизировать включение поля даты создания и даты последнего обновления во все таблицы БД?

Мой босс в настоящее время пытается применить некоторые стандарты разработки к нашей команде, поэтому вчера у нас было совещание, чтобы обсудить стандарты, которые в основном шли хорошо, пока она не подняла вопрос:

• Все таблицы БД будут иметь столбцы CreatedDate и LastUpdatedDate, обновленные триггерами.

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

Я твердо в бывшем лагере. Хотя я понимаю, что некоторые внешние случаи могут привести к тому, что дополнительные столбцы улучшат поддерживаемость, на мой взгляд, объем работы, который потребуется для добавления столбцов в первую очередь, а также обслуживания, заставил бы нас тратить меньше времени на большее важные вещи, такие как модульное или нагрузочное тестирование. Кроме того, я вполне уверен, что из-за этих дополнительных столбцов было бы более неудобно использовать ORM, учитывая, что мы в основном используем C # и Oracle, что не очень радует ORM.

Итак, мой вопрос состоит из двух частей:

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

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

Если вы имеете дело с любыми финансовыми или чувствительными данными, я уверен, что вы слышали о таких вещах, как соответствие PCI и SOX . Наличие всестороннего контрольного журнала имеет важное значение для удовлетворения этих требований.

Отказ от ответственности: Тем не менее, существуют гораздо лучшие способы получения контрольного журнала базы данных> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails

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

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

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

... чем более убедительные утверждения делает человек, тем больше вероятность, что он ошибается окончательно ... - Тайлер Дурден

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

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

Я полностью согласен. Почти каждая таблица в каждой базе данных должны иметь по крайней мере , 2 поля: дата создания и дата обновления . Есть много причин, по которым вы должны указать дату создания и дату обновления. По очевидным причинам, которые заявили предыдущие люди ... что такое аудит.

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

Есть 2 основных способа сделать это:

1 - Первая практика - позволить базе данных выполнить работу и поместить ее непосредственно в дизайн таблицы. Какой минимум, я бы порекомендовал.

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

Еще одним преимуществом наличия этих полей является хранилище данных и ODS, которые ВСЕГДА создаются для любой системы OLTP. Вы не можете эффективно получить инкрементные данные без него. В противном случае вы рискуете перезагружать всю БД каждый день.

Существует огромное количество других деловых причин для вставки этих двух дат, которые я не буду вдаваться в подробности. Сделайте свою домашнюю работу, и я уверен, что через 3-6-12-48 месяцев в будущем вы будете очень счастливы, если вы введете эти два простых поля.

Я реализовал и обычно рекомендую оба решения, где это возможно.

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

Я не могу представить ни одно приложение Enterprise, которое не нуждается в аудите той или иной формы. Видимо, ваш начальник считает, что для этого нужен только относительно мягкий аудит. Лично я предпочитаю проводить полный аудит каждой базы данных, в которой содержатся данные, от которых зависит ваша компания (гораздо проще восстановить эти 2000 неверных записей из таблиц аудита, чем восстанавливать резервные копии), и мне это потребуется, если вообще есть какая-либо финансовая информация, как я видел, что такого рода вещи помогают поймать людей, совершающих мошенничество. Весь аудит должен быть на уровне базы данных.

Как эти данные могут помочь? Ну, во-первых, он сужает, когда нужно искать старые данные (в редакции), и он может помочь вам увидеть, какая версия вашей программы была активной во время ввода данных. Так что, если вы знаете, что исправили эту проблему в версии 2.3, которая была запущена 6 июля 2011 года, а затем обнаружили ту же проблему с записью, вставленной 7 августа, то, возможно, ваше исправление не было хорошим. Если вам нужно вернуться к старым данным, вам сообщат, в какой версии резервных копий вы можете найти старые данные, если у вас нет полного аудита.

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

Рабочая нагрузка спорная, потому что это может быть написано в сценарии и применено к любой базе данных, которую вы когда-либо создадите. Добавьте столбцы во все таблицы вместе с триггерами. Вы просто должны помнить, чтобы запустить его со своей сборкой.

Насколько клиент хочет, вы можете заставить его платить вам за интеграцию в ваше приложение по своему усмотрению. Многим нравится видеть дополнительную информацию о записи, например, кто создал / изменил ее в последний раз и когда. Не нужно отправлять всем электронную почту, чтобы узнать или обмануть. Вам не нужно запрашивать журнал каждый раз, когда кто-то просматривает запись.

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

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

Во-первых, для добавления столбцов понадобится оператор alter table, все таблицы alter будут одинаковыми (кроме имени таблицы), поэтому вы можете написать скрипт для кода, генерирующий оператор alter SQL для всех необходимых таблиц. , Необходимо разрешить NULL учитывать существующие данные и проверять наличие столбцов, чтобы их можно было повторно запускать.

Во-вторых, для столбцов использование значений по умолчанию, таких как GetUTCDate () (SQL Server, Oracle может отличаться), разрешает любые добавления кодирования при вставке, поэтому кодовая база не должна изменяться ни для одного из операторов вставок, поскольку значения по умолчанию будут используемый.

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

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