Archief - [PROG]Java Hibernate and Multi Databases

Hoi,

ik vraag me af of er hier iemand ervaring heeft met meerdere database en Hibernate voor java...

en als iemand me wat meer uitleg zou kunnen bieden over het onderwerp of eventueel wa voorbeeld code heeft hoe dit precies in zijn werk zou kunnen gaan?


grtz me

Is het dit dat je zoekt: http://www.hibernate.org/414.html ?
Heb je de documentatie al eens gelezen?

Ice zei:

Is het dit dat je zoekt: http://www.hibernate.org/414.html ?
Heb je de documentatie al eens gelezen?

Klik om te vergroten...

effen lezen...

ja sorry, ma de link van Shards naar multi db's leg ik toch nie direct ze

en google didn't came up with shards

alvast bedankt

edit: wel spijtig dat nog in beta is
The initial release of Hibernate Shards is currently in beta-testing phase and is available for download.

effen mss nog wa meer uitleg aan hand van vb:
Tis de bedoeling dat vb per Gebruiker een DB bestaat (uit de zelfde tabelen) en als de gebruiker dat iets opslaat dat het dan in de juiste DB terecht komt.

Ice zei:

Is het dit dat je zoekt: http://www.hibernate.org/414.html ?
Heb je de documentatie al eens gelezen?

Klik om te vergroten...

heb het effen gelezen en ik denk dat die shards eerder bedoeld zijn om immens grote database' te kunnen opsplitsen...,

zou mss wel mee lukken om per gebruiker een db aan te maken, elke object da ik dan zo saven zo dan een identity (gebruiker) moeten hebben waar het naar toe moet...

en blijkbaar is het ook nog nie op een simple manier mogelijk om vb data uit een db te lezen...zonder veel gepruts...

ma khad alvast nog ess verder bekijken , ziet er wel intersant uit om mss ess met te testen

grtz me

Mmhz mjah shards is idd als je data over meerdere gespreide db's hebt zitten, in dit geval niet echt de oplossing. Nu, per gebruiker en eigen db is weird. Heb je hier echt een heel goede reden voor?

Je kan het 'simpel' doen door: 1 master db met daarin per gebruiker de connectie data voor zijn db, maar ik zou alles gewoon in 1 db steken. Lijkt me veel simpeler & logischer.

Ice zei:

Mmhz mjah shards is idd als je data over meerdere gespreide db's hebt zitten, in dit geval niet echt de oplossing. Nu, per gebruiker en eigen db is weird. Heb je hier echt een heel goede reden voor?

Je kan het 'simpel' doen door: 1 master db met daarin per gebruiker de connectie data voor zijn db, maar ik zou alles gewoon in 1 db steken. Lijkt me veel simpeler & logischer.

Klik om te vergroten...

De reden is simple, aangezien we dus een online applicatie gaan maken die dus een aantal gebruikers heeft, ma per gebruiker zal er al zoiezo imens veel informatie zijn, nen gebruiker heeft dus opzicht al verschillende tabellen. Dus in plaats van 1 grote DB waar we dus querty op laten doen enzo eigenlijk teveel informatie moeten overlopen van ander gebruikers, hadden we gedacht op 1 db per gebruiker te pakken zodat het "systeem" direct de juiste data kan accessen zonder onnodig ander gebruikers zijn data te gaan queryen...
Ook om al een beetje in begin toch een splitsing te hebben indien we met een max-aantal records per dbserver ergens vastlopen...

Volgende reden is als er in de toekomst beslist wordt om er toch een offline variant van te maken zou het heel handig zijn als we een per gebruiker al een DB hebben, het zou dan veel simpler zijn deze te synchroniseren dan te synchroniseren met een db waar alle info inzit...

Gebruiker die wenst niet meer deel te nemen is dan ook heel handig te verwijderen (gewoon db weg doen) zonder dat er enig risco is dat er toch (ook al probeerde bugloos te programmeren) ergens een ander record van iemand zou mee verdwijnen als ge op basis van een gebruikers id een inmens grote database opkeusd.

die shards ziet er wel goed uit, ma het enigste is dat het uitlezen voor de moment nog gebeurt uit alle DB tegelijk en dat we niet kunnen selecteren welke we willen uitlezen, och nie zonder "te prutsen" en da elke saveobject dus de parent een identy moet hebben omteweten in welke DB het moet komen... wat mss ook nog nie echt onoverkomelijk was.

Inderdaad dat er een masterDB gaat moeten zijn met daarin dus gebruiker infot en hun db connectie, maar mijn probleem zit eerder dan bij hibernate hoe ik dat dig wijs maakt dat hem nu deze connectie moet gebruiken, aangezien een Session maar één connectie kan doen en hem dan zo zo moeten switchen...

heb namelijk nog maar enkel ervaring met hibernate als alles in DB zit...

http://www.codeproject.com/useritems/NHibernateMultipleDBs.asp

dit ziet er mss nog wel iets uit om ess te proberen... wel spijtige genoeg in C

voor de rest vin ik nie echt degelijk voorbeelden

Overweeg opnieuw of je echt een DB per gebruiker nodig hebt. Wat een vreselijke duplicatie is dat. En hoe relevant is die data dan in het geheel?

Verder, shards is niet wat je nodig hebt. Dat gaat over distributie imo. Je kan proberen met Hibernate te werken, en dat lijkt me niet zo moeilijk, zorg gewoon dat je aan de juiste Sessionfactory geraakt per user. Andere user, andere SessionFactory met andere config. Het wordt pasmoeilijk als je zoals hierboven wilt gaan lazy loaden, dan moet je wat kunstgrepen gaan toepassen in het raamwerk ivm config.

En dan nog, als je perse multiple DB's wilt, en het gaat om enorme hoeveelheden data, is Hibernate dan de aangewezen keuze? Dat lijkt me een use-case voor wat low-level JDBC. Uw connectie-code zal pak simpelere zijn.

Mja db per gebruiker lijkt mij altijd slecht, als ge dan later als admin queries wilt trekken over alle data, plezant
Snap zowiezo het probleem niet echt, zijn dat een vijftal gebruikers die allemaal miljoenen records aanmaken ofzo?
Teveel informatie overlopen, deftig DB-design + deftige queries waar nodig doet wonderen

Trouwens die masterDb zie ik nu ook niet echt problemen, als dat enkel een test is van usersecurity + connectie db ophalen is, daar hoeft nu niet speciaal hibernate voor gebruikt te worden, beetje overkill.

Voor offline te gaan later is het wel intressant, heb begin dit jaar een kleine test hier gedaan met NHibernate (.net) zodat onze dal gebruikt kon worden voor Oracle (online) em Sqlite (offline), werkte zeer makkelijk, gewoon aparte mappingfiles gebruiken

Uiteindelijk een tijdje NHibernate blijven gebruiken, totdat we uiteindelijk wat tijd hadden om te refactoren en de NHibernate er kompleet uigesmeten

Admin gaat nooit nie queries over het ganse systeem moeten trekken...

Ik zou per gebruikern een db maken omdat het ander echt wel een soep wordt en hoogstwss veel records zullen worden gegenereerd. Ik kan nie op voorhand weten als het bij 5 gebruikers blijft of 50 of 500...
Een ding weet ik wel Per gebruiker wordt er dit ongeveer allemaal bijgehouden
Elke gebruiker heeft zijn Contacten, Leveranciers, Klanten, Transacties, Transactieboeken, Artikels enzo...

Als ik dan alles bij elkaar zou steken in één grote db da zo vb de Contacten tabel wel echt eens uit de hand kunnen lopen kwa records...(tezien hoeveel gebruikers er zijn), zelfde met transacties enzo...

Of begrijp ik nu verkeerd dat een DB met tabellen van 500000 records rapper gaat zijn dan een aparte db van één gebruiker waar er mss 1000 in zitten?

Ook als er een offline versie komt is synchroniseren met een grote DB een pain in the...vin ik toch

en vooral omdat de info per gebruiker echt uniek is aan de gebruiker dus de aner gebruikers noch admin's noch ik zou enige reden hebben om uit alle db's tegelijk alle klanten te willen...

Of begrijp ik nu verkeerd dat een DB met tabellen van 500000 records rapper gaat zijn dan een aparte db van één gebruiker waar er mss 1000 in zitten?

Klik om te vergroten...

Deftig DB-design en dat maakt niet veel verschil, zelfde als synchroniseren, maak niet uit als het 1 Db is, is nog het minst van uw zorgen, zoals ik het versta kan een record alleen maar geupdate worden door 1 gebruiker dus dan is het poepsimpel

Ik zie eerder problemen met administratie + backup nemen van 50/500/+ db's

Gaat het over minder dan een miljoen records? Serieus man, dan heb je zulke truken niet nodig. Ik dacht dat het ging om een data-mining systeem ofzo, met zeer specifieke herhalende data en queries, dna is JDBC aangewezen. Jij hebt een vrij simpele standaard setup van een enterprise systeem. Dat kan elke DB aan indien juist geconfigureerd.

tmagus zei:

Admin gaat nooit nie queries over het ganse systeem moeten trekken...

Ik zou per gebruikern een db maken omdat het ander echt wel een soep wordt en hoogstwss veel records zullen worden gegenereerd. Ik kan nie op voorhand weten als het bij 5 gebruikers blijft of 50 of 500...
Een ding weet ik wel Per gebruiker wordt er dit ongeveer allemaal bijgehouden
Elke gebruiker heeft zijn Contacten, Leveranciers, Klanten, Transacties, Transactieboeken, Artikels enzo...

Als ik dan alles bij elkaar zou steken in één grote db da zo vb de Contacten tabel wel echt eens uit de hand kunnen lopen kwa records...(tezien hoeveel gebruikers er zijn), zelfde met transacties enzo...

Of begrijp ik nu verkeerd dat een DB met tabellen van 500000 records rapper gaat zijn dan een aparte db van één gebruiker waar er mss 1000 in zitten?

Ook als er een offline versie komt is synchroniseren met een grote DB een pain in the...vin ik toch

en vooral omdat de info per gebruiker echt uniek is aan de gebruiker dus de aner gebruikers noch admin's noch ik zou enige reden hebben om uit alle db's tegelijk alle klanten te willen...

Klik om te vergroten...

Gebruik 1 database en voeg in iedere tablel een extra veld toe zodat je de gebruiker uniek kan refereren. Als uw querys zullen dan iets bevatten in den aard van: '..... where userid = ....'.

Qua onderhoud gaat het ook veel eenvoudiger zijn, zeker als je backup/restore/performance moet gaan verzorgen voor 5/50/500 dbs ipv 1.
En ge moet u echt geen zorgen maken over nen tabel waar eens een 500 000 records in zitten.

Dan over uw punten van het is eenvoudiger, als alles in 1 database zit is het nog eenvoudiger.
1 Gebruiker toevoegen ---> user bijmaken in user table.
1 Gebruiker verwijderen ---> user op disabled zetten en voila, later kan je dan af & toe cleanup laten lopen die alle data van gedisablde users verwijderd.

En nog 1 pluspunt aan 1 DB,
Tis vrij makkelijk om die later indien toch nodig te splitsen in meerdere DB's,
Moest ge de verschillende DB's per gebruiker moe worden qua administratie en naar 1 DB willen gaan zit ge zwaar in de shit
(behalve natuurlijk als ge der op voorhand rekening mee houdt (userid-stuff))

Tenzij je het hebt over een access database zie ik geen enkele reden waarom dit niet in een enkele database kan. Als je 50000 of 1000 records moet overlopen, dit zal geen kat merken, het is een verschil van een aantal miliseconden. De veel gebruikte database systemen zijn zodanig geoptimaliseerd dat ze makkelijk een groot aantal records aankunnen zonder dat de gebruiker er veel van merkt. Een enkele database is ook veel handiger naar backups toe. Een klein beetje professioneel systeem moet de mogelijkheid hebben om gemakkelijk een backup te nemen.