Flevostrand rulez! - It's a bird NO It's a plane NO IT IS SUPER SNACKMAN
Verwijderd
Ik vind inderdaad ook dat databases geheel los van elkaar horen te staan en dat dit soort constructies niet netjes zijn. Echter in sommige gevallen als je aan iets bestaands gebonden zit kan het misschien een praktische oplossing zijn. Maar zelf zoiets ontwerpen zou ik toch niet aan beginnen...
Het principe is juist dat een database een bij elkaar horende groep tabellen is, als je ze op deze wijze koppelt vervalt dat nogal
Het principe is juist dat een database een bij elkaar horende groep tabellen is, als je ze op deze wijze koppelt vervalt dat nogal
Verwijderd
Ik vind het van belang wat de relatie van de data tot elkaar is en of het werkelijk in 2 databases thuis hoord. Als het om techniesche redenen niet mogelijk is om er 1 database van te maken dan zou ik het wel zo houden omdat je anders een extra tabel moet aanmaken en dit tegen de regels van het normaliseren is, toch? Anders maak er gewoon 1 tabel van.
voor het moment zit ik in zo een situatie.
Voor mijn stageopdracht moet ik namelijk connecties maken met reeds bestaande databases (customers enzo ...).
In mijn eigen database moet ik zodus ook FK hebben die verwijzen naar die customers, ... van die bestaande databases.
Dus het kans soms wel noodzakelijk zijn.
En ik zie ook niet direct in wat daarnu vuil aan zou zijn?
Voor mijn stageopdracht moet ik namelijk connecties maken met reeds bestaande databases (customers enzo ...).
In mijn eigen database moet ik zodus ook FK hebben die verwijzen naar die customers, ... van die bestaande databases.
Dus het kans soms wel noodzakelijk zijn.
En ik zie ook niet direct in wat daarnu vuil aan zou zijn?
[ Voor 47% gewijzigd door Feyd-Rautha op 16-04-2003 12:17 ]
I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. Where the fear has gone there will be nothing. Only I will remain.
mysql kent geen tablespaces en gaat met databases bijna net zo om als andere rdbms-en met tablespaces doen.
Als je het zo beschouwd is het wel handig, daar waar je in Oracle met meerdere tablespaces zou werken doe je dat in mysql dan met meerdere databases. Anderzijds zijn databases in principe normaliter zo gescheiden dat het niet netjes is.
Bijvoorbeeld een centrale-user-'tabel' zou je in oracle waarschijnlijk in een eigen tablespace stoppen en dan met je andere applicaties (waarvan de tabellen in gescheiden table-spaces zitten) benaderen, dat kan in mysql niet en alles maar samengooien in 1 tabel is ook niet altijd de beste oplossing
Als je het zo beschouwd is het wel handig, daar waar je in Oracle met meerdere tablespaces zou werken doe je dat in mysql dan met meerdere databases. Anderzijds zijn databases in principe normaliter zo gescheiden dat het niet netjes is.
Bijvoorbeeld een centrale-user-'tabel' zou je in oracle waarschijnlijk in een eigen tablespace stoppen en dan met je andere applicaties (waarvan de tabellen in gescheiden table-spaces zitten) benaderen, dat kan in mysql niet en alles maar samengooien in 1 tabel is ook niet altijd de beste oplossing
kan dat normaal wel dan? sql server oid?Super Snackman schreef op 16 april 2003 @ 11:42:
Heya all,
ik ben wat gaan testen en doen met Mysql/InnoDB en ik kwam iets in mijn ogen merkwaardigs tegen. Het is namelijk mogelijk om foreign keys te leggen tussen tabellen in verschillende databases.
Hoe netjes is dit? Ik vind het zelf al vrij slecht dat als je in een analyse vind dat tabellen bij elkaar horen, dat je ze toch in verschillende databases zet.
Wat vinden jullie ervan?
Pagina: 1