Zelfde Query tegelijk over meerdere databases op server

[wsql]

Goedendag,

Ik heb een vrij lange Query maar wil nu ook de data uit 12 exact dezelfde databases op dezelfde server ophalen (andere administraties).

Is hier een handige manier voor?

Ik heb wat zitten proberen met een Join maar het lukt mij alleen maar als ik dan alle velden 12 keer opneem met een verwijzing naar de juiste database. Zo is het wel een hele lang Query en niet erg handig als er iets moet worden aangepast.

Is er een mogelijkheid dat ik een code opneem om de Query op alle vermelde databases te laten draaien. Zoiets als USE Database1, Database2 enz.


from Database1.dbo.absenses a
join Database2.dbo.absenses b on a.HID = b.HID


B.v.d. voor jullie hulp

[ricom]

Als het dezelfde query is met dezelfde velden, gaat het dan niet lukken met een Union ?

[RobIII]

Maak een view over die 12 databases en "schuif het onder de mat"? (Met, zoals @ricom, zegt, gebruik van een union)

[ Voor 28% gewijzigd door RobIII op 23-06-2021 18:29 ]

[The Eagle]

Technisch kan dit, bijvoorbeeld met behulp van een database link.
In de DB van waaruit je de zaak aanroept maak je DB links aan naar de respectievelijke bron DB's, en dan kun je idd iets doen als je in je voorbeeld zelf aangeeft. Exacte syntax onder SQL server is mij even onbekend

Dat gezegd hebbend:
- Als jij een select over een DB link doet kan je explain plan van je query vrij onvoorspelbaar zijn. De bron DB kan namelijk niks anders doen als een full table scan, omdat de query optimizers van de DB's los van elkaar draaien. Dat kan op iedere losse DB een piekbelasting veroorzaken

- Als jij uit meerdere DB's data nodig hebt dan ben je vermoedelijk met iets BI achtigs bezig en niet met een operationele rapportage. gebruik daar dan ook een BI tool voor, of iig iets dat de data los heeft.

Mocht het zo zijn dat je alleen maar losse DB's hebt en geen BI tool, dan zou ik er altijd voor kiezen om de data uit die bron DB's over te halen naar je execute DB, en dan de query pas te draaien. Maar ook daar geldt dat je goed moet kijken of je DB wel voor dat soort doeleinden geschikt of bedoeld is.

[RobIII]

The Eagle schreef op vrijdag 25 juni 2021 @ 14:09:
Technisch kan dit, bijvoorbeeld met behulp van een database link.
In de DB van waaruit je de zaak aanroept maak je DB links aan naar de respectievelijke bron DB's, en dan kun je idd iets doen als je in je voorbeeld zelf aangeeft. Exacte syntax onder SQL server is mij even onbekend

Volgens mij is 't OP wel duidelijk dat het kan (en ook de syntax), zie de topicstart, maar OP wil weten of de query kan zonder 12 keer een database te moeten noemen.

[nescafe]

Zoiets al veelvuldig gedaan. Let erop dat deze sp meerdere result sets teruggeeft; dus vooral handig in SSMS, daarbuiten niet echt.
[code=sql]
sp_msforeachdb 'IF ISNUMERIC(''?'') = 1 AND LEN(''?'') = 3
SELECT ID, Description
FROM [?]..Absences
WHERE Type = 0'
[/code]

Anders lees ik de vraag even goed.. nee joinen tussen db's gaat je zo niet lukken.

[ Voor 14% gewijzigd door nescafe op 25-06-2021 14:26 ]

[The Eagle]

RobIII schreef op vrijdag 25 juni 2021 @ 14:16:
[...]

Volgens mij is 't OP wel duidelijk dat het kan (en ook de syntax), zie de topicstart, maar OP wil weten of de query kan zonder 12 keer een database te moeten noemen.

In verband met aanpassingen enzo, nou zie ik het ja.
Kan technisch ook. Meest ranzige oplossing: een view bouwen die alle data uit die tabellen bij elkaar veegt (simpele union is het makkelijkste) en de query op die view loslaten.
Als je de view aanspreekt haalt ie alle data uit die diverse absense tabellen op, leest in memory / temp tablespace en doet daar de de select op. En als je iets anders moet selecteren: query op de view aanpasen.

Als er geen real time criterium aan zit zou ik voor een materialized view gaan met een refresh in de nacht. Staat het er dagelijks

Laat onverlet dat je nog steeds die DB links zult moeten gebruiken voro een verbinding van DB naar DB.
Enige DBMS waarvan ik weet dat ie het ook zonder DB links kan is Snowflake. maar dat zal hier vast niet gebruikt worden

[RobIII]

The Eagle schreef op vrijdag 25 juni 2021 @ 14:40:
[...]

In verband met aanpassingen enzo, nou zie ik het ja.
Kan technisch ook. Meest ranzige oplossing: een view bouwen die alle data uit die tabellen bij elkaar veegt (simpele union is het makkelijkste) en de query op die view loslaten.
Als je de view aanspreekt haalt ie alle data uit die diverse absense tabellen op, leest in memory / temp tablespace en doet daar de de select op. En als je iets anders moet selecteren: query op de view aanpasen.

Je bent nog niet helemaal wakker, wel?

Maar je hebt gelijk; efficiënt is 't niet, en vrij ranzig inderdaad.

The Eagle schreef op vrijdag 25 juni 2021 @ 14:40:
[...]
Als er geen real time criterium aan zit zou ik voor een materialized view gaan met een refresh in de nacht. Staat het er dagelijks

Waarom dan nog een view en niet gewoon een table?

The Eagle schreef op vrijdag 25 juni 2021 @ 14:40:
Laat onverlet dat je nog steeds die DB links zult moeten gebruiken voro een verbinding van DB naar DB.

Dat lijkt me niet echt een probleem noch de vraag?

[sig69]

The Eagle schreef op vrijdag 25 juni 2021 @ 14:40:
[...]
...
Laat onverlet dat je nog steeds die DB links zult moeten gebruiken voro een verbinding van DB naar DB.
Enige DBMS waarvan ik weet dat ie het ook zonder DB links kan is Snowflake. maar dat zal hier vast niet gebruikt worden

MS SQL kan dat ook prima (ik vermoed dat het hier om gaat, gezien de voorbeeld query)

[sig69]

RobIII schreef op vrijdag 25 juni 2021 @ 14:42:
[...]

Maar je hebt gelijk; efficiënt is 't niet, en vrij ranzig inderdaad.

Ranzig, ja misschien wel een beetje. Maar inefficiënt? Elke query op elke database zal z'n eigen plan wel trekken. Dat is echt het probleem niet.

[RobIII]

sig69 schreef op zaterdag 26 juni 2021 @ 00:29:
Elke query op elke database zal z'n eigen plan wel trekken.

Ik vind 't een vrij gevaarlijke aanname, maar meten == weten. Dus dan heeft OP iets te doen

[sig69]

Wij/ik/ons bedrijf deed (doet, nog een beetje) dat vaak genoeg. In MS SQL geen enkel probleem in ieder geval. Voor realtime inzichten kan je soms niet anders.

[ Voor 19% gewijzigd door sig69 op 26-06-2021 00:37 ]