[MySQL] Tables symlinken?

[Olaf van der Spek]

Ik heb vier databases. In deze vier zou ik graag een aantal tabellen hebben die globaal zijn, en dus niet per db. Weet iemand of dit mogelijk is? In het FS zelf kun je symlinks gebruiken, maar kan zoiets ook in MySQL?

Het alternatief is om alle queries die deze globale tabellen gebruiken aan te passen.

[LoBbY_1]

Hoe bedoel je dit? Wil je je database bronbestanden gebruiken via symlinks? Het lijkt me dat de bestanden gelocked zijn als ze in gebruik zijn.. Of wil je een tabel in meerdere databases voor laten komen?

[pedorus]

Een VIEW gebruiken?

[Creepy]

Waarom niet een extra database aanmaken voor deze globale tabellen?

[Olaf van der Spek]

Creepy schreef op donderdag 06 mei 2010 @ 15:40:
Waarom niet een extra database aanmaken voor deze globale tabellen?

Dan kan ik alsnog "alle queries die deze globale tabellen gebruiken aanpassen".

pedorus schreef op donderdag 06 mei 2010 @ 15:30:
Een VIEW gebruiken?

Komt in de buurt, maar is niet ideaal.

[Soultaker]

Mja, een extra database lijkt me inderdaad ook de oplossing.

Symlinken is ontzettend hacky en ik kan me voorstellen dat 't allerlei problemen geeft met transacties omdat MySQL niet verwacht dat lokale updates (binnen een database) invloed hebben op tables in een andere database.

Gewoon niet aan beginnen en simpelweg een aparte database met gedeelden rechten opzetten. MySQL kan voor zover ik weet prima transacties en queries waarbij meerdere database betrokken zijn uitvoeren.

Dan kan ik alsnog "alle queries die deze globale tabellen gebruiken aanpassen".

Schrijf er een scriptje voor? Hoe moeilijk kan het zijn om

sed -r 's/(FROM|INTO) TabelNaam/\1 DataBase.TabelNaam/'

op je queries te runnen?

(Wellicht is het in de praktijk íets ingewikkelder maar het lijkt me geen onoverkomelijk probleem, dat wel in de beste eindsituatie resulteert.)

[ Voor 32% gewijzigd door Soultaker op 06-05-2010 15:53 ]

[Olaf van der Spek]

Soultaker schreef op donderdag 06 mei 2010 @ 15:45:
Symlinken is ontzettend hacky en ik kan me voorstellen dat 't allerlei problemen geeft met transacties omdat MySQL niet verwacht dat lokale updates (binnen een database) invloed hebben op tables in een andere database.

Symlinks op FS niveau zijn natuurlijk uit den boze, ik hoopte op symlinks op MySQL niveau.

[lier]

Olaf van der Spek schreef op donderdag 06 mei 2010 @ 15:43:
Dan kan ik alsnog "alle queries die deze globale tabellen gebruiken aanpassen".

Maar wat bedoel je hier precies mee ?
Heb je het dan over rechten ?

[Soultaker]

Wat was overigens het bezwaar tegen een view? Wil je ook updates toen tegen de lokale tabel (dat kan niet met een view) of is er iets anders?

(In principe kun je een view maken zodat je je read-only queries in ieder geval niet aan hoeft te passen, dat hoef je alleen de queries die updates doen op de tabel nog om te schrijven. Maar ik blijf erbij dat 't mooier is om maar één tabel in één database te gebruiken.)

[Verwijderd]

Het hele idee van aparte databases is toch dat je data niet naar andere databases kan lekken? Nou ga je daar weer "gaten doorheen boren".
Als de vier databases gerelateerd zijn, maak er dan 1 database van met een prefix voor de vier verschillende toepassingen in de tabelnamen.

[pedorus]

Soultaker schreef op donderdag 06 mei 2010 @ 15:58:
Wil je ook updates toen tegen de lokale tabel (dat kan niet met een view) of is er iets anders?

quote: http://dev.mysql.com/doc/refman/5.1/en/create-view.html

Some views are updatable. That is, you can use them in statements such as UPDATE, DELETE, or INSERT to update the contents of the underlying table. For a view to be updatable, there must be a one-to-one relationship between the rows in the view and the rows in the underlying table. There are also certain other constructs that make a view nonupdatable.

[Olaf van der Spek]

Soultaker schreef op donderdag 06 mei 2010 @ 15:58:
Wat was overigens het bezwaar tegen een view? Wil je ook updates toen tegen de lokale tabel (dat kan niet met een view) of is er iets anders?

Bijvoorbeeld:

The view definition is “frozen” at creation time, so changes to the underlying tables afterward do not affect the view definition. For example, if a view is defined as SELECT * on a table, new columns added to the table later do not become part of the view.

Views zijn trouwens wel updatable.
Ik ga toch maar queries aanpassen...

Verwijderd schreef op donderdag 06 mei 2010 @ 16:01:
Het hele idee van aparte databases is toch dat je data niet naar andere databases kan lekken? Nou ga je daar weer "gaten doorheen boren".
Als de vier databases gerelateerd zijn, maak er dan 1 database van met een prefix voor de vier verschillende toepassingen in de tabelnamen.

Dan kan ik nog veel meer queries updaten.

[ Voor 26% gewijzigd door Olaf van der Spek op 06-05-2010 16:21 ]

[Voutloos]

Extra db is imo gewoon de oplossing, als dat meer werk is so be it. Kan je meteen ervoor zorden dat database names niet meer hardcoded zijn / te configureren zijn, wat erg fijn kan zijn bij het vergelijken/testen van database wijzigingen.

[Verwijderd]

Oracle heeft hiervoor een zogenaamde "database link", dat is volgens mij de term die je zoekt.Het lijkt er op dat MySQL een dergelijke constructie niet kent.

[Olaf van der Spek]

Verwijderd schreef op donderdag 06 mei 2010 @ 18:24:
Oracle heeft hiervoor een zogenaamde "database link", dat is volgens mij de term die je zoekt.Het lijkt er op dat MySQL een dergelijke constructie niet kent.

Dat is iets anders (volgens mij), MySQL equivalent db.table in plaats van table.

[Verwijderd]

Volgens mij stiekem niet, staat daar tevens een feature request voor open. Daar wordt dan weer wel doorverwezen naar een 'Fedorated table', is dat wat je zoekt?

[Olaf van der Spek]

Je hebt gelijk, Oracle kan er meer mee dan MySQL. Maar nog steeds niet wat ik wil. Met federated tables kan het, maar:

It is possible for a FEDERATED table to use another table that is managed by the same server, although there is little point in doing so.

[SiErRa]

Het is misschien handig om te vermelden waarom je dit eigenlijk wil.

Over het algemeen maak je verschillende databases omdat ze gevuld zijn met data voor verschillende applicaties. En daarom wil je juist dat ze niet met elkaar communiceren.

Als je toch queries over databases wil maken voor BI doeleinden kan je beter een staging database maken en daar alles periodiek inladen en vervolgens op die database je queries loslaten.

Maar als ik je goed begrijp wil je er ook in muteren. Dat zou betekenen dat je 1 frontend hebt die op meerdere applicaties of services werkt. Dan zou misschien eens naar je applicatie architectuur moeten kijken.

[Olaf van der Spek]

Ik heb vier databases met dezelfde structuur voor vier games. Vroeger draaiden deze games op aparte servers, dus volledig onafhankelijk, nu draait alles op een server.

[Verwijderd]

Zoals eerder aangegeven lijkt een extra database mij inderdaad de beste oplossing. Je tegenwerping dat je alle queries moet gaan aanpassen klopt maar lijkt me ook onvermijdelijk. Het is nu veel werk, maar als je in de toekomst weer aanpassingen moet doen in je database of applicatie ben je jezelf er dankbaar voor. Stel je voor dat je vier games heel groot worden. Dan gaat dit zeker een bottleneck worden of tenminste een last.

[Olaf van der Spek]

Helaas worden de games alleen maar ouder en minder populair.

[Verwijderd]

En je wilt tussen verschillende databases praten omdat.... je speler informatie ineens samenkomt op 1 server ofzo? Maar dan kan je toch nog steeds losse spelers per spel hebben, en dus losse speler tables? Zoniet, maak een spel onafhankelijke speler database aan, zodat het "inloggen" los staat van het spelen van een spel.

[beetle71]

• Nieuwe database aanmaken;
• alle 'dubbele' tabellen uit de originele databases daarin in enkelvoud aanbrengen.
• Tabel in orginele database verwijderen en vervangen door een 'straight' view op de nieuwe database (select * from) en de view noemen als de originele tabel.

Voordeel: je hoeft niks aan je code aan te passen. Met een view op deze manier kun je gewoon door de view heen updaten/inserten.

Nadeel: performance. Maar of je daar echt last van hebt hangt af van hoe die tabel eruit ziet. Hoeveel records etc. Als je geen hele gekke dingen of gigantische tabellen hebt, wordt dit aardig opgevangen door de caching van mysql.

[steffex]

als de tabellen niet al te groot zijn, lijkt me het makkelijkste dat je gewoon een centrale db aanmaakt voor deze tabellen zoals meeste mensen hierboven al wel aangeven.

Performance is dan ook nog wel prima...

[CyBeRSPiN]

Wat je wilt is een synonym maken (mits alle databases op dezelfde server), maar ook dat lijkt niet in MySQL te kunnen.
Een synonym is in feite een symlink, je hoeft dan niet te prefixen met de databasenaam.

[Olaf van der Spek]

stef-o schreef op vrijdag 07 mei 2010 @ 12:27:
als de tabellen niet al te groot zijn, lijkt me het makkelijkste dat je gewoon een centrale db aanmaakt voor deze tabellen zoals meeste mensen hierboven al wel aangeven.

Performance is dan ook nog wel prima...

Wat heeft performance hiermee te maken? Een tabel is een tabel... Toch?

beetle71 schreef op vrijdag 07 mei 2010 @ 11:05:
[list]
Nadeel: performance. Maar of je daar echt last van hebt hangt af van hoe die tabel eruit ziet. Hoeveel records etc. Als je geen hele gekke dingen of gigantische tabellen hebt, wordt dit aardig opgevangen door de caching van mysql.

Laat een van de tabellen nu net 2 gb zijn.

[ Voor 33% gewijzigd door Olaf van der Spek op 07-05-2010 13:38 ]

[beetle71]

Laat een van de tabellen nu net 2 gb zijn.

Mmm... blijft er niet veel meer over dan proberen.
Originele tabel even hernoemen, view aanmaken met de oude naam. Dat is <1 min werk. Daarna even performance testen.
Teveel performance verlies? Jammer, view weggooien en tabel weer 'terugnoemen'
Ik schat dat het performance verlies erg meevalt,

Mijn ervaring met tabellen views met >10^7 records - daar zitten views op ivm rechten, waardoor er dus WHERE statements in de view zitten - is is dat het nauwelijks(lees: niet) merkbaar is. Maar dat kan in jouw geval anders zijn

je 'voordeel' zit aan de andere kant ook weer in het feit dat je DBengine nog maar 1 tabel hoeft te cachen (om 4 views te voeden) ipv. 4 tabellen....