Query met tabelnaam "like"

[Andre1234]

Ik wil graag gegevens halen uit vele tabellen, welke dezelfde kollommen hebben, die een vaste naam hebben met daarachter een datum
bijvoorbeeld:
database.tabelnaam_20200101
database.tabelnaam_20200102
database.tabelnaam_20200102
database.tabelnaam_20200103
enz

Is er manier om de tabelnaam met een like o.i.d. uit te voeren bijv:

SELECT column1, column2 FROM database.tabelnaam_2020%1

Hiermee zou je elke table welke begint met 2020 afgevraagd worden

Ik ben geen SQL pro en kan op internet niet echt duidelijke voorbeelden vinden.

[The Eagle]

Met puur SQL ga je dit miet afdekken, dan moet je met een stukje scripting of andere DB technieken aan de slag.
Oracle kent bijvoorbeeld PLSQL, en MS kent T-SQL.

Key is dat je je sql statement dynamisch wilt genereren in deze.

Met het handje is overigens vrij simpel, dan gebruik je de UNION operator.

[Coltrui]

Ofwel begrijp ik het niet goed, ofwel moet je even googelen op je DMBS + "table metadata" en op basis hiervan een script genereren...

[ Voor 18% gewijzigd door Coltrui op 29-11-2020 15:55 ]

[KabouterSuper]

Je sql-dialect is nogal belangrijk. In oracle kan je dit voor elkaar krijgen met een package een wat slimme dynamische trucs. In msacces gaat het je zeker niet lukken. Maar in alle gevallen zal het niet standaard zijn. Gewoonlijk normaliseer je je database en zal je uitkomen op één grote tabel met een datum-kolom.

[ikweethetbeter]

Het is wel handig om te zeggen in welke DB je dit wilt doen!

[BCC]

Kan je het niet in de applicatie oplossen ?

[RobIII]

De vraag is natuurlijk waarom je voor elke dag een nieuwe tabel hebt. Waarom zit dit niet allemaal in 1 tabel met een datumveld

De oplossing is overigens vrij simpel; pas de applicatie aan zodat die nog naar 1 tabel gebruikt (en een "where <datum>" waar nodig). En met een simpel scriptje hevel je die data zo over in de nieuwe tabel waarna deze tabellen weg kunnen.

[ Voor 48% gewijzigd door RobIII op 29-11-2020 16:39 ]

[StevenK]

Andre1234 schreef op zondag 29 november 2020 @ 13:22:
Ik wil graag gegevens halen uit vele tabellen, welke dezelfde kollommen hebben, die een vaste naam hebben met daarachter een datum
bijvoorbeeld:
database.tabelnaam_20200101
database.tabelnaam_20200102
database.tabelnaam_20200102
database.tabelnaam_20200103
enz

Is er manier om de tabelnaam met een like o.i.d. uit te voeren bijv:

SELECT column1, column2 FROM database.tabelnaam_2020%1

Hiermee zou je elke table welke begint met 2020 afgevraagd worden

Ik ben geen SQL pro en kan op internet niet echt duidelijke voorbeelden vinden.

Nee, want als je die select wil doen, doe je feitelijk een union over al die tabellen. Ik zou met een loop alle tabellen die aan het criterium voldoen naar een temp table dumpen en dan van daaruit je data selecteren.

[Coltrui]

RobIII schreef op zondag 29 november 2020 @ 16:35:
De vraag is natuurlijk waarom je voor elke dag een nieuwe tabel hebt. Waarom zit dit niet allemaal in 1 tabel met een datumveld

De oplossing is overigens vrij simpel; pas de applicatie aan zodat die nog naar 1 tabel gebruikt (en een "where <datum>" waar nodig). En met een simpel scriptje hevel je die data zo over in de nieuwe tabel waarna deze tabellen weg kunnen.

Tenzij je cross-database wil werken - zie in de OP 'database.' staan, vandaar deze bedenking

[ Voor 6% gewijzigd door Coltrui op 29-11-2020 20:27 ]

[sig69]

StevenK schreef op zondag 29 november 2020 @ 16:37:
[...]

Nee, want als je die select wil doen, doe je feitelijk een union over al die tabellen. Ik zou met een loop alle tabellen die aan het criterium voldoen naar een temp table dumpen en dan van daaruit je data selecteren.

Een loop en een temp table, 2 performance killers terwijl een (al dan niet gegenereerde) union volstaat. Goed idee.
Maar @RobIII heeft gelijk, als je invloed hebt op de applicatie die deze data genereert zou een aanpassing aan het data model de voorkeur hebben.

[Barreljan]

In geval van MySQL

SELECT DISTINCT(TABLE_NAME)
FROM `information_schema`.`COLUMNS`
WHERE TABLE_NAME LIKE 'tabelnaam_2020%';

Maar ergens kan je je afvragen of je dat wil doen. Wat eerder al gezegd word, wellicht is er een betere manier. Elke dag een table is vaak om een hele specifieke reden.

Deze query kan als je als subquery gebruiken, maar echt efficiënt word het er niet mee. En `information_schema` is nou niet echt waar mee je bezig moet zijn.

[ Voor 8% gewijzigd door Barreljan op 03-12-2020 15:49 ]

[hostname]

Barreljan schreef op donderdag 3 december 2020 @ 15:47:
In geval van MySQL

SELECT DISTINCT(TABLE_NAME)
FROM `information_schema`.`COLUMNS`
WHERE TABLE_NAME LIKE 'tabelnaam_2020%';

Maar ergens kan je je afvragen of je dat wil doen. Wat eerder al gezegd word, wellicht is er een betere manier. Elke dag een table is vaak om een hele specifieke reden.

Deze query kan als je als subquery gebruiken, maar echt efficiënt word het er niet mee. En `information_schema` is nou niet echt waar mee je bezig moet zijn.

Lekker inefficiënt, alle kolommen queryen om tabellen te vinden. Kan je beter zo doen:

SQL:

SELECT TABLE_NAME 
FROM information_schema.TABLES 
WHERE TABLE_SCHEMA = 'database' AND TABLE_NAME LIKE 'tabelnaam_2020%';

Maar ook hier ben je er nog niet mee, want dit geeft je slechts alle tabelnamen, en niet de inhoud daarvan. Alles mergen naar dezelfde tabel is inderdaad de betere oplossing.

[Barreljan]

hostname schreef op donderdag 3 december 2020 @ 15:57:
[...]

Lekker inefficiënt, alle kolommen queryen om tabellen te vinden. Kan je beter zo doen:

SQL:

SELECT TABLE_NAME 
FROM information_schema.TABLES 
WHERE TABLE_SCHEMA = 'database' AND TABLE_NAME LIKE 'tabelnaam_2020%';

Maar ook hier ben je er nog niet mee, want dit geeft je slechts alle tabelnamen, en niet de inhoud daarvan. Alles mergen naar dezelfde tabel is inderdaad de betere oplossing.

Eens. Ik was ook even snel in een php dingetje geklommen en daar word er nog een onderscheid gemaakt op tabellen met specifieke column name. Dus niet goed de query hier ten toon gesteld en de distinct is dus ook pointless als je de juiste query doet.

[drm]

Wat je nog veel beter kunt doen is het zaakje migreren naar een tabel die gepartitioneerd* is. Dan heb je dit soort ellende in de toekomst ook niet meer.

*) ik gok zomaar dat je MySQL gebruikt