Jak zapisać dowolną kolekcje obiektów za pomocą Hibernate

Witam,

Mam pytanie jak za pomocą Hibernate zapisać kolekcję obiektów jako jedną komórkę w tabeli (serializacja?).
Mianowicie mam klasę Faktura która ma w sobie kolekcję obiektów Produkty, chciałbym żeby w jednym wierszu tabeli była zapisana faktura z odwzorowanymi atrybutami (data,kwota,itd.), oraz z ww. kolekcją Produktów do niej należącej.

Standardowo powinna być to zwykła relacja "jeden do wiele", jednak wartości atrybutów produktu są unikalne dla każdej faktury, tak więc przy 100 fakturach i 500 produktach na każdej z nich wielkość tabeli Produkty była by ogromna.
Wydaje mi się że lepsza by była możliwość przechowywania dodanych produktów w kolekcji indywidualnej dla każdej faktury.

Prosił bym o jakieś sugestie jak można zrealizować to co napisałem powyżej, lub o inne sposoby rozwiązania tego problemu.

Nie kombinuj w ten sposób. Jeżeli obawiasz się, że tabela produkty ci urośnie to zrób inaczej:

class Faktura{
  transient List<Produkt> produkty;
  ObjectStream produktyAsStream;
//...
}

I teraz Hibernate będzie zapisywał nie listę a strumień jako BLOB, a ty w getProdukty() będziesz sobie już to odpowiednio odczytywał.

jestes pewien ze to dobre rozwiazanie ? a jak bedziesz chcial zrobic jakis raport z tych danych ? albo bedziesz mial potrzebe zmienic cokolwiek na tej fakturze bezposrednio przez sql'a. takich rzeczy raczej sie nie robi. a ogromna ilosc rekordow to tak >mln :) jak tego bedzie mniej niz kilkadziesiat tysiecy to przecietny komputer sobie z tym poradzi.

Domyślam się, że ogromna ilość danych zaczyna się >mln ale np. po 5 latach (gdzie trzymasz wszystkie faktury) nie trudno uzyskać taką ilość w tabeli :).

Jeżeli chodzi o raporty myślałem żeby zrobić w ten sposób, że stworzę nową tabele gdzie każdy wiersz będzie inną fakturą i zawierał będzie nr faktury kontrahent wartość netto brutto itp. na podstawie tego już można robić raporty.

Edycja faktur chcę żeby była możliwa jedynie z poziomu GUI.

Czy w takim wypadku rozwiązanie Koziołka jest OK ??

Czy mimo wszystko trzymać się tego żeby w bazie były odwzorowane dane?

Myślałem jeszcze nad takim rozwiązaniem żeby dla każdej nowej faktury tworzyć osobną tabele "ProduktTempNrFaktury" w ten sposób tabel zrobi się więcej ale będą miały powiedzmy po 100 wierszy. Tylko pytanie jak jest wydajniej w takiej sytuacji dla bazy więcej tabel z mniejszą ilością wierszy czy jedna tabela TEMP gdzie jest np. 800 000 wierszy.

Sorry za górę pytań ale nie jestem doświadczonym programistą a to jest moja praca inżynierska.

Pomysł z tworzeniem osobnej tabeli na specyfikację każdej faktury jest, imo, idiotyczny. Pomyśl o takim, bardzo naturalnym, pytaniu: ile i za ile sprzedaliśmy towaru xxx? Jeśli masz 100tys. faktur, to będziesz musiał pobierać informacje z 100tys. tabel.

No faktycznie teraz widzę że to głupi pomysł :/

@eeee, zmiana bezpośrednio przez SQL to zuo :)

Jeżeli chodzi o raportowanie. Problem jest ciekawszy. Po pierwsze trzeba wiedzieć co chcemy raportować. Jeżeli wystarczą tylko kwoty faktur to nie trzeba zbytnio kombinować tylko w tabeli Faktura trzymać te informacje w prost. Gorzej jeżeli chcemy mieć stany magazynowe. Wtedy warto trzymać sobie tabelę produkty z informacjami o wydanych i przyjętych na stan. Tyle tylko, że wtedy baza rośnie.

@kazhiu, opisz na jakiej mniej więcej maszynie ma to działać. Może się okazać, że można robić to najprostszymi metodami, a nie kombinować tak jak teraz to robimy.

zuo ? :) to sprobuj wdrozyc nowa wersje z nowym schematem bazy i upgrejdowac istniejace dane :P to samo dotyczy raportow, nie da sie przewidziec od razu wszystkich, a w przypadku takich systemow zawsze jakis dyrektor handlowy wpadnie na pomysl nowego raportu. generalnie to w bazach danych chodzi wlasnie o przechowywanie duzej ilosci latwo dostepnych danych. w przypadku faktur to z reguly dominuja inserty ktore zawsze dzialaja szybko a raporty sie robi hurtownia danych(olapy itp) wiec o wydajnosc nie ma sie co martwic. takie tabele tez duzo zyskuja na partycjonowaniu. ogolnie to bazy danych oferuja cala mase rozwiazan zarzadzania duza iloscia danych i nie ma co kombinowac jak kon pod gore

@eeee, aktualizacja bazy, a grzebanie i "poprawianie" danych to dwie różne rzeczy. Zresztą np. hibernate potrafi zaktualizować scheme przy uruchomieniu. Co do nowych raportów to świetnie sprawdza się JasperReports + iReports. Jeżeli dobrze to zorganizujesz to raport można zrobić w 4 dni z czego 3 dni to wyżywanie się artystyczne.
Swoją droga ostatnio siedzę nad fakturami. Zasada nr 1. ma być jak najprościej. Zasada nr 2. ma być jeszcze prościej. Wielkością bazy się nie przejmuję, bo i tak zawsze będzie za wolno :D

oczywiscie, ze hibernate to zaktualizuje, chyba ze zmiana dotyczy 'schematu' trzymanego jako blob a taki pomysl sie w tym watku przewija. z tego co ja wiem, to zeby bylo zgodnie ze sztuka to taka fakture nalezy rozbic na zupelne atomy. wszystkie systemy ERP tak robia. a jak bedzie 'za wolno' to w 90% jest to blad w strukturze bazy(klucze, indeksy, partycje itp) albo kiepskie zapytanie :P
jesli chodzi o raporty to i tak zazwyczaj nie robi sie tego na 'zyjacej' bazie tylko stawia sie hurtownie danych przy ktorej redundancja danych jest rzecza wskazana i raport masz w 4h a nie 4dni :P

ok, czyli rozumiem że najlepszym rozwiązaniem będzie trzymać w bazie czyste wartość ?? nie kombinując ze strumieniami itp.
aplikacja będzie chodziła na jakimś core 2 duo więc myślę, że faktycznie wielkością bazy za bardzo się nie przejmować. Może tylko zrobić tak żeby co roku zakładać nową tabelę dla produkty_temp żeby ta tabela nie rosła w nieskończoność :) ??

Możesz sobie zrobić inaczej. Masz dwie tabele. Produkty i produkty_arch. Wstawiając do jednej triger przepisuje do drugiej. Raz na pewien czas odpalany jest scheduler, który czyści dane. Trzeba tylko sobie ustawić za ile czasu robione są raporty. Zazwyczaj wystarczą 3 miesiące.

kazhiu napisał(a)

(...)Może tylko zrobić tak żeby co roku zakładać nową tabelę dla produkty_temp żeby ta tabela nie rosła w nieskończoność :) ??

juz chyba trzeci raz pisze ze wystarczy jedna tabela + partycjonowanie :) artykul o mssql - http://www.microsoft.com/poland/technet/article/art0178.mspx
a jak chcesz robic raporty na powaznie to poczytaj o technologi OLAP i Hurtowniach Danych - http://pl.wikipedia.org/wiki/Hurtownia_danych