Znalazłem się w sytuacji, w której trzymanie obiektów w bazie wydaje mi się najlepszym z możliwych wyjść. Musiałem założyć ten wątek, bo automatycznie zapala to u mnie czerwoną lampkę i skojarzenia, że "to samo zło". Ale jednak.
Problem, do rozwiązania:
- jedną z głównych encji w aplikacji są instancje klas potomnych do klasy bazowej Service, które mają po kilka customowych dla siebie pól, własne strategie generowania swojego "opisu" i generowania wartości dla pól wspólnych.
- wszystkie te informacje są konieczne do przechowania w takiej postaci, w jakiej były wygenerowane na moment utworzenia instancji (czyli np. zmiana klasy i sposobu generowania wartości powinna wpłynąć jedynie na nowe instancje).
Pomysł jest taki, by w jednej tabeli trzymać pełne, zserializowane obiekty, a w innej ich uproszczone do kilku wspólnych kolumn wersje. Także wszystkie listingi, filtry i raporty będą odpytywać normalne dane w tabelach, a dopiero widok szczegółów odtworzy obiekt na podstawie uuid.
Mongo i inne NoSQL raczej odpadają, bo nie mam z nimi takiego doświadczenia produkcyjnego jak np. z Postgresem, a bezpieczeństwo danych i niezawodność bazy są w tym wypadku kluczowe.
Co o tym myślicie?