[alg] meerdere databases in 1 systeem.

[Alarmnummer]

Ik neem aan dat jullie het wel eens zijn tegengekomen. Een heel systeem waarin verschillende databases in principe 1 geheel vormt. Dit is typisch iets dat je ziet bij systemen die al een tijd in gebruik zijn. Ik wil graag weten hoe jullie hier mee om gaan. Hoe ga je om met de queries (bv de joins), hoe ga je om met transacties? Hoe ga je om met integriteit?

[djluc]

Is een oplossing als: alles in 1 database zetten geen mogelijkheid?

[Alarmnummer]

djluc schreef op 08 november 2004 @ 17:52:
Is een oplossing als: alles in 1 database zetten geen mogelijkheid?

Helaas Ik ben dus niet op zoek naar hoe het beter had gekund.. uiteraard is alles in 1 databases zetten de beste oplossing, maar dit is niet altijd mogelijk. Wat dan.. daar ben ik in geinteresseerd.

Is er bv een systeem waarmee je die losse databases kunt samenvoegen tot 1 virtuele?

[ Voor 13% gewijzigd door Alarmnummer op 08-11-2004 17:57 ]

[djluc]

maar dit is niet altijd mogelijk

Verklaar je nader.. Wat zou, behalve aanpassingen wat betreft de toegangsrechten eventueel, je belemmeren dit te doen?

[Alarmnummer]

djluc schreef op 08 november 2004 @ 18:02:
[...]
Verklaar je nader.. Wat zou, behalve aanpassingen wat betreft de toegangsrechten eventueel, je belemmeren dit te doen?

Tja.. dat kunnen legio dingen zijn, bv legacy systemen (inclusief hun databases) waar je niet meer van af komt (om wat voor reden dan ook.. ). Ik ben dus niet geinteresseerd in hoe het beter kan.. ik ben alleen geinteresseerd in: ok.. het is kut.. wat nu?

[ Voor 7% gewijzigd door Alarmnummer op 08-11-2004 18:30 ]

[Annie]

disclaimer: ik kan alleen spreken over MSSQL, andere systemen heb ik geen ervaring mee.

joins
Geen probleem als je de databasenaam vermeld in je object aanroep. Je kan zelfs joinen naar een database op een andere server/instance als je dat zou willen.

transacties
In feite heb je gewoon te maken met distributed transactions, al worden deze door MSSQL zelf afgehandeld (afaik). Pas als je aan de slag gaat over meerdere servers wordt het wat ingewikkelder.

integriteit
Integriteit afdwingen via FK constraints gaat je niet lukken. Dus dat zal je zelf moeten regelen.

[watzie]

In Sybase kun je daarvoor proxy tables definieren, zijn een soort van virtuele tables in jouw database die naar een andere wijzen.
Daarmee kun je queries/joins/transactions etc dus gewoon afhandelen alsof het 1 database is.

Aanspreken vanuit Java moet dan wel met jdbc >= 2 en een XA compatible driver (XA driver geldt ook voor niet java spul natuurlijk).

Overigens: als je het hebt over 'verschillende databases', kan dat een aantal dingen betekenen voor verschillende dbms'en.
In Sybase heb je een dataserver. Op een dataserver draai je meerdere databases. Per machine kun je evt ook nog meerdere dataservers hebben, maar natuurlijk ook meerdere machines.
Verschillende databases kun je op de (ansi?)sql manier dus database.owner.table manier doen. Zodra je cross dataserver gaat (al dan niet een andere machine dus) heb je een proxy table nodig.
In Oracle gaat dit weer heel anders. Hoe die dingen allemaal precies heten weet ik effe niet meer uit m'n hoofd, maar daar heb je weer een heel andere hierarchie. Wat ik me herinner is iig dat op een hele fysieke machine jeniet 2x dezelfde objectnaam (sp, table, trigger) mag hebben maar pin me er niet op vast, lang geleden.

Ik denk eigenlijk dus dat er geen 'algemene' oplossing is, die is dbms specifiek.

Het komt wel heel vaak voor dat er meerdere databases zijn die je wilt koppelen. Gaat het om 1 systeem/programma dat ook de enige consumer is van alle databases, dan is het wel een goed idee om ze samen te voegen in 1 database. Zo niet, dus er zijn meerdere applicaties die de databases gebruiken dan valt er weinig aan te doen denk ik.

[ Voor 64% gewijzigd door watzie op 08-11-2004 19:05 . Reden: verschil tussen nomenclatuur. ]

[Verwijderd]

Ik moet wel eerst even vermelden dat ik me hoofdzakelijk bezig houd met het schrijven van programma`s in Visual Basic 6. Maar het principe van het gebruiken van meerdere databases gebruik ik.

Ik gebruik gewoon (zeg maar) een standaard Access databases waarbij de unieke code uit de ene database correspondeerd met de ander. Mocht uit de hoofddatabase de unieke code verwijderd zijn dan werkt de aanliggende ook niet meer. Dit heb ik als "beveiligde" koppeling gedaan. Er is maar 1 nadeel, de aanliggende database zal langzamer zeker steeds voller raken, wat als voordeel heeft dat de geschiedenis bewaard blijft. Mijn principe werkt gewoon volgens een paar databases die op verschillende netwerk -servers bevinden. Stel dus; een paar lokaal, een paar interlokaal en een paar landelijk. Via HTTP protocollen haal ik bijvoorbeeld ook elke keer (per week) de laatste database binnen met bijvoorbeeld de meest recente adresseringen.

Ik denk dat het in principe via MSSQL ook moet kunnen, MITS je de unieke code uit de hoofddatabase (op verzoek) direct kan aanmaken als record in de aanliggende database. (ik heb geen ervaring met MSSQL)

Ik hoop dat je dr wat aan hebt.

[Alarmnummer]

Kijk.. dit is informatie waar ik iets aan heb.

Weet iemand of MS SQL Server hier ook ondersteuning voor heeft? (Met deze
database werk ik op dit moment voornamelijk).

[ Voor 18% gewijzigd door Alarmnummer op 08-11-2004 18:58 ]

[watzie]

Alarmnummer schreef op 08 november 2004 @ 18:58:
Kijk.. dit is informatie waar ik iets aan heb.

Weet iemand of MS SQL Server hier ook ondersteuning voor heeft? (Met deze
database werk ik op dit moment voornamelijk).

Welke versie van mssql heb je het over? MSDN geeft vast wel antwoord trouwens.

Maar dikke kans dat het erin zit (of iets vergelijkbaars), want t/m ms sqlserver 6.5 en sybase 10 waren deze hetzelfde programma, alleen onder twee verschillende namen verkocht. Na de splitsing zijn ze beiden hun eigen weg gegaan, echter ze delen natuurlijk nog een hele hoop core functionaliteit en de structuren lijken erg op elkaar.
Ik heb zelf tot nu toe altijd alles vrij makkelijk van sybase naar mssql kunnen porten, omgekeerd is moeilijker want ms heeft wel heel veel (vaak mooie) nieuwe fratsen toegevoegd.

[Kuhlie]

Alarmnummer schreef op 08 november 2004 @ 18:58:
(...)

Weet iemand of MS SQL Server hier ook ondersteuning voor heeft? (Met deze
database werk ik op dit moment voornamelijk).

Annie schreef op 08 november 2004 @ 18:40:
disclaimer: ik kan alleen spreken over MSSQL, andere systemen heb ik geen ervaring mee.

(uitleg geknipt)

Ik gok dat het kan

[Alarmnummer]

Kuhlie schreef op 08 november 2004 @ 19:23:
Ik gok dat het kan

*veegt de stront ff uit zijn ogen*.. ik dacht toch werkelijk MySQL te lezen ip MSSQL.

[Casteloni]

Je kan met een J2EE Application server ook gebruik maken van verschillende databases. Zo kan je per entiteit een datasource opgeven. Het maakt dan helemaal niet uit waar je je gegevens uithaalt.

[Noork]

Ik zou toch proberen om de database langzamerhand naar 1 database over te hevelen.

Ik snap trouwens niet waarom het niet mogelijk zou zijn. Heb je dan nog oude cobol applicaties of soortgelijke programma's draaien met hun eigen databases?

[Alarmnummer]

VampireSlayer schreef op 08 november 2004 @ 19:35:
Je kan met een J2EE Application server ook gebruik maken van verschillende databases. Zo kan je per entiteit een datasource opgeven. Het maakt dan helemaal niet uit waar je je gegevens uithaalt.

Je kunt in een applicatieserver datasources opgeven, dat is idd waar. Maar het bied je geen andere functionaliteit (met uitzondering van EJB-CMP). Dus de zaken waar ik aan zit te denken.. joins... transacties.. integriteit die moeten wel op een of andere manier toegevoegd worden.

[Soultaker]

Ik weet dat er ook transaction managers zijn, die een front-end bieden voor verschillende databases tegelijk. Die lossen dan gelijk de issues m.b.t. transaction safety op. Helaas heb ik daar nooit wat mee gedaan dus echt specifieke informatie heb ik niet.

Ik kan me voorstellen dat het erg lastig is als je veel verschillende databaseservers gebruikt, maar als ze allemaal (bijvoorbeeld) een ODBC interface hebben is de kans dat je ze gezamelijk kunt aanspreken wel groter, lijkt me.