Serializowane obiekty w bazie SQL - uzasadnienie praktyczne

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?

Jak rozumiem, potrzebujesz przechowywać w bazie hierarchię klas. Nie potrzebujesz wyszukiwania po jakichś polach tych klas? W przypadku trzymania zserializowanych obiektów będzie to utrudnione i niewydajne.

Do wyszukiwania będzie służyć inna tabela. Specyficzne pola klasy potrzebne będą jedynie w widoku typu details.

Doszedłem jednak do wniosku, że wrzucę to do JSONB Postgresa i będę mapował pola tam i z powrotem. Chcę uniknąć dużej liczby wartości null w kolumnach, a tak by było w klasycznym podejściu.

Potencjalny fuckup przy serializacji na długą metę: http://stackoverflow.com/questions/17338057/php-unserialize-an-object-without-the-matching-class

Zależy co nazywasz "klasycznym podejściem"? W klasycznym podejściu możesz mieć np. jedną tabelę na pola klasy bazowej oraz po jednej tabeli dla każdego typu dziedziczącego, i nie mieć żadnych nulli.
Klasycznym podejściem jest też podejście Entity-Attribute-Value, tam też nie masz nulli, za to zapytania stają się dość utrudnione, no ale plusem jest to, że łatwo dodawać nowe pola do klas, i można to robić nawet dynamicznie.

Czułem, że będą problemy z tym stwierdzeniem, ale pisałem z telefonu i potrzebowałem skrótu myślowego:).

Dzięki, bo przedstawiłeś dwie ciekawe alternatywy. Trochę mi głupio, że sam nie wpadłem na tę pierwszą :D. Zacznę od jsonów, bo mam to już rozgrzebane. Jak będą problemy, to spróbuję innych podejść.

Miłego dnia :)