С созданной меткой времени лучше управлять БД или приложением?

Question

Мы разрабатываем ваше стандартное стандартное Java-приложение, и многие создаваемые нами записи (объекты Hibernate в MySQL) имеют «созданные» и «модифицированные» временные метки.

Теперь я и один из разработчиков не согласны - я считаю, что оба этих поля должны иметь MySQL по умолчанию CURRENT_TIMESTAMP, и тогда измененное может быть изменено приложением. Он хочет, чтобы оба управлялись приложением.

Есть ли веская причина для любого решения? Я не понимаю, почему вы хотите добавить более явные шаги к коду, если только по какой-то причине вы не обеспокоены тем, что ваши серверы (БД, приложения) имеют несовместимые метки времени.

Answer 1

• используйте временные метки БД, если вы можете пожертвовать переносимостью. Кроме того, если очень небольшие различия будут иметь значение для приложения, и у вас будет более одного сервера приложений / кластера, у вас могут возникнуть проблемы с синхронизацией узлов.
• используйте приложение для генерации меток времени, если нет уверенности, что выбранная БД останется, или если вы используете несколько баз данных - например, MySQL для производства, HSQLDB для юнит-тестов.

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

Если вы решите обработать приложение, либо перейдите к предложению Pascal Thivent с помощью @PreUpdate, либо установите для своего поля значение по умолчанию, например:

private Calendar date = Calendar.getInstance();

Answer 2

Я бы справился с этим из кода и использовал бы @ PrePersist и @ PreUpdate Hibernate / JPA * обратные вызовы:

@PreUpdate
@PrePersist
public void setTimeStamps() {
    modified = new Date();
    if (created==null) {
      created = new Date();
    }
}

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

Answer 3

Имеет смысл выделить все временные метки на одном уровне для согласованности.

Этот ответ на связанный вопрос дает хороший пример того, как это сделать в Hibernate.

Answer 4

Я бы использовал триггеры и хранимые процедуры для поддержки этих полей.Поэтому поместите логику в БД.