сохранение / загрузка общего типа Java в столбец базы данных postgresql

#java #generics #postgresql

#java #общие сведения #postgresql

Вопрос:

Я пытаюсь реализовать некоторые простые функции аудита для моего Java-приложения. Вот фрагмент моего класса аудита:

 public class Audit<C, T> {
    public final Class<C> modifiedClass;
    public final Date modificationTime;
    public final MyFieldMeta<C, T> fieldMeta; //contains Class<T>
    public final T newValue;

    //constructor, etc...
}
  

Когда дело доходит до сохранения этих объектов аудита, я бы предпочел иметь только одну таблицу, хранящую все варианты независимо от того, что T есть. Я использую postresql, и мне интересно, каков наилучший подход для сохранения newValue в столбец, а затем получения его обратно.

newValue ограничивается довольно простыми типами, которые имеют эквиваленты postgresql — String , Integer , Date и т.д. Таким образом, сохранить значение как text и тип как varchar в отдельном столбце, а затем отобразить их обратно в java было бы не слишком сложно. Есть ли более простой подход?

Ответ №1:

Как только вы «выровняете» типы данных в своей базе данных, вы будете полагаться на логику для обратного преобразования, что может вызвать проблемы. Рассмотрим значение: 11.12

Это текст 11.12, как в номерах глав? Это 11.12 в денежном выражении? Это 11 декабря?

Если вы не можете гарантировать, что значение всегда может быть четко сопоставлено типу, единственный способ обойти это — добавить дополнительный маркер типа к полю, который затем необходимо разобрать, например: s11.12 для обозначения «строки со значением 11.12».

Комментарии:

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

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