Zdravim konferenci, tak jsem se nad tim trosku vic zamyslel. Nejprve proc jsem to tak chtel. Zde jsou duvody pro rozdeleni do jednotlivych tabulek pro kazdeho klienta (terminal):
1) bezpecnost - mozna vychazi z dob Foxky apod. starsich databazi, kdy kazda tabulka byla jednim souborem. Proste jsem mel pocit, ze pri poruseni integrity dat (ke kteremu by teoreticky nemelo nikdy dojit, ze... ale...:) takhle system na chvili prijde jen o jednoho klienta (nez se pripadne obnovi ze zalohy). 2) efektivnost - mozna opet zastaraly nazor, ale rozdelenim na vice tabulek jsem chtel dosahnout i vyssi efektivnosti prace s daty tabulky. Kazdy den totiz budou pribyvat do tabulky stovky, mozna tisice novych zaznamu (radku). Tim se dostavam k 3 duvodu... 3) "archivovani" - mel jsem dokonce takovou predstavu, ze se po jiste dobe presunou zaznamy z aktualni tabulky terminalu do jakesi archivni, abych praci s aktualni tabulkou urychlil a do tabulky archivni pristupoval pouze v pripade potreby. Hm, jak se dnes resi takove problemy? Pocet zaznamu tabulky muze nabyvat ohromnych cisel. Prace s takovou tabulkou pak muze neunosne (a zbytecne - potrebuji jen mimoradne pristup ke vsem datum) zpomalovat cely system. A na zaver jeste jeden dotaz primo k PostreSQL. Mate nekdo zkusenosti s jejim zalohovanim? Jake postupy se vam osvedcily? S pozdravem, Petr Gola PS: Reseni s dvemi session factory se mi nelibi - na klientovy zadna session factory nebezi (a chtel bych se tomu vyhnout:), klient je pouze kukatko, session factory obsahuje business vrstva, tudiz by na ni muselo bezet 1+n session factories pro n klientu. On 6/11/06, Jiří Melichna <[EMAIL PROTECTED]> wrote:
Dobry den, v mem navrhu jsou jen dve session factory - kazdy klient ma nakonfigurovane 2: 1x publicFactory 1x specificFactory Na kazdem nodu se tak lisi pouze nejaky kofiguracni soubor. V RDBMS je pak jedno schema spolecne - sem je smerovana publicFactory a n schemat pro terminaly, vzdy se stejnou tabulkou (schema ja napr. v Oracle urcena uzivatelem). Problem, ktery vidim, je hlavne nebezpeci dvoufazoveho commitu a nemoznost udelat elegantni JOIN. Uz jsem neco podobneho pouzil, ale to jsem mel jeste malinko jinak - spolupracovaly nody s globalni DB a kazdy nod mel doplnkovou lokalni DB. Mimochodem, proc neni tabulka 1x do ni nejsou terminaly mapovany pomoci jednoho sloupce jako klic jsem s jistotou nepochopil. melichnj > ------------ Původní zpráva ------------ > Od: Petr Gola <[EMAIL PROTECTED]> > Předmět: Re: Hibernate - ukladani jedne tridy do vice tabulek > Datum: 09.6.2006 20:06:33 > ---------------------------------------- > Uprimne, byl jsem Hibernate nadsen, ale nyni jsem mirne zklaman. Stale > hledam jine reseni, prece nejsem jediny, kdo toto musel resit. > Aplikace je 3-vrstva, takze bych musel mit na business vrstve 1 > session factory pro spolecna data a pak n dalsich pro n pripojenych > klientu. To se mi nelibi. > > S pozdravem, > > Petr Gola > > On 6/9/06, Jiří Melichna <[EMAIL PROTECTED]> wrote: > > Dobry den, > > > > ja nevim, ale zneuziti dedicnosti na toto tema se mi zda ponekud silna kava. > Osobne se domnivam, ze bude nutno zavest do aplikace dve session factory. Jedna > pro spolecna data a druha pro data konkretniho terminalu. Pak v kazdem schematu > (rec Oracle) nad kterou bude session terminalu bude stejna tabulka obsahujici > jen data od terminalu. Problem vidim hlavne v nutnosti dvoufazoveho commitu a to > dokonce i v pripade, ze se jedna o pripojeni na jednu DB. Jako dalsi problem > vnimam nemoznost vytvaret bez dalsi podpory na strane DB JOINY mezi tabulkami > jadra a tabulkami terminalu. Na druhou stranu je tento pristup asi genericky a > je mozno libovolne a rychle rozsirovani. > > > > melichnj > > > > > ------------ Původní zpráva ------------ > > > Od: Lukas Barton <[EMAIL PROTECTED]> > > > Předmět: Re: Hibernate - ukladani jedne tridy do vice tabulek > > > Datum: 09.6.2006 18:23:53 > > > ---------------------------------------- > > > Petr Gola napsal(a): > > > > No, problem je takovy: > > > > > > > > Mam na databazi pripojeno nekolik rekneme terminalu a chci, aby kazdy > > > > z nich ukladal svoje data do sve vlastni tabulky (z mnoha duvodu - > > > > bezpecnostnich, snadneho zalohovani atd. to nechci do jedne tabulky). > > > > Takze tabulek muze byt obecne n, jak toto resit dynamicky dedicnosti > > > > vazne nevim:) > > > > > > > Tak reseni s Hibernatem bych videl nasledujici: pri vytvareni session > > > factory se na objektu Configuration zavola addXML(String xml), do > > > ktereho se dynamicky vygeneruje odpovidajici mapovani - napr. nacteni ze > > > souboru a nasledna uprava odpovidajiciho elementu. > > > > > > Lukas > > > > > > > > > > > > > > > > >
