MySQL keresés összes táblában

Adatbázis: SQL, XML DB

Sziasztok!

Vannak egy bizonyos adatbázison belül több táblák, mindegyiknek értelemszerűen más a neve, viszont szerkezetileg ugyanazok, csak a tartalom más. A kérdés, hogy hogy lehet ezekben keresni úgy, ha keresek, akkor az összes táblában keressen megadott mezőben, amit én megadok.

Esetleg valami ötlet?

köszi

  • 2712 megtekintés

( haspokember | 2015. 03. 20., p – 18:22 )

Kapcsold ossze a SELECT-jeidet UNION-okkal.

SELECT column1, column2
FROM table1
UNION
SELECT column3, column4
FROM table2
UNION
...

Ez lehet egy subselect, vagy common table expression is (ez utobbit nem tudom, MySQL tamogatja-e mar...).

Ha nagyon sok tablad van, vagy ha dinamikusan valtoznak, akkor ez nem jarhato ut, akkor is meg lehet hackelni, de ott mar valami buzlik az adatmodell korul...

Milyen gyakran jön létre/szűnik meg új tábla? A tábla módosítós részbe tegyél be plusz egy kérést, hogy updateljen egy nézet táblát (itt programokból fel kell sorolnod az union-hoz a táblákat), akkor már tudsz benne egyben keresni.

Amúgy ha szabad megkérdezni: miért nem rakod össze a 7-800 táblát egy táblába, kiegészítve egy mezővel, amiben azt tárolod, ami alapján szétdobáltad őket táblákra?

(Szerk.: egy tippem van, hogy a jogosultságok miatt kell őket külön táblába szervezni, de ha jól emlékszem ezt fordítva [egy tábla, abból nézetek, azokhoz jogosultság] meg lehet oldani)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nagyjából úgy működik a dolog, hogy számítógépeinkről készítünk csv-ben exportot, és ezeket a csv-ket töltöm fel LOAD DATA LOCAL INFILE paranccsal mysql-be. Eredetileg 1 táblába menne, az a tábla kb. ~800x3500 sor lenne, ami még annyira nem is nagy baj, viszont updatelni szintén nem tudom hogy lehet 3500 sort egy LOAD-dal.

The REPLACE and IGNORE keywords control handling of input rows that duplicate existing rows on unique key values:

If you specify REPLACE, input rows replace existing rows. In other words, rows that have the same value for a primary key or unique index as an existing row. See Section 13.2.7, “REPLACE Syntax”.

If you specify IGNORE, rows that duplicate an existing row on a unique key value are discarded.

If you do not specify either option, the behavior depends on whether the LOCAL keyword is specified. Without LOCAL, an error occurs when a duplicate key value is found, and the rest of the text file is ignored. With LOCAL, the default behavior is the same as if IGNORE is specified; this is because the server has no way to stop transmission of the file in the middle of the operation.

Ha a kulcsok rendben vannak, akkor Replace ezt meg kellene, hogy oldja. (a SET-el pedig be tudod állítani a korábban táblákra elosztó mezőt)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

test-gep1.csv 


foo;bar;baz
lorem;ipsum;dolor

test-gep2.csv 


foo;bar;barbaz
lorem;ipsum;sit

SQL: 


CREATE TABLE test ( gep VARCHAR(4), field1 VARCHAR(10), field2 VARCHAR(10), field3 VARCHAR(10), PRIMARY KEY (gep, field1, field2) );
LOAD DATA INFILE '/home/****/test-gep1.csv' REPLACE INTO TABLE test FIELDS TERMINATED BY ';' (field1, field2, field3) SET gep='gep2';
LOAD DATA INFILE '/home/****/test-gep2.csv' REPLACE INTO TABLE test FIELDS TERMINATED BY ';' (field1, field2, field3) SET gep='gep2';

Ekkor a tábla tartalma: 


+------+--------+--------+--------+
| gep  | field1 | field2 | field3 |
+------+--------+--------+--------+
| gep1 | foo    | bar    | baz    |
| gep1 | lorem  | ipsum  | dolor  |
| gep2 | foo    | bar    | barbaz |
| gep2 | lorem  | ipsum  | sit    |
+------+--------+--------+--------+

Átírva a test-gep1.csv-t [mondjuk a baz-t bazbaz-ra] és a fenti paranccsal újra importálva: 


Query OK, 3 rows affected (0.05 sec)                 
Records: 2  Deleted: 1  Skipped: 0  Warnings: 0

A Deleted-nél látszik, hogy a (gep1, foo, bar) kulcs miatt volt egy ütközés, így azt a rekordot felülírta a CVS-ben levő adatokkal: 


+------+--------+--------+--------+
| gep  | field1 | field2 | field3 |
+------+--------+--------+--------+
| gep1 | foo    | bar    | bazbaz |
| gep1 | lorem  | ipsum  | dolor  |
| gep2 | foo    | bar    | barbaz |
| gep2 | lorem  | ipsum  | sit    |
+------+--------+--------+--------+

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nos sikerült kipróbálni. Viszont a bibi, hogy csak 1 sort rögzít be a csv-ből, a legutolsót. Viszont egy csv sokkal több sort tartalmaz. Viszont ha van egy AUTO_INCREMENT mezőm, egyből benne van az összes sor a csv-ből 3 gép 10 ezer sor, viszont ez ismét csak insertel és nem updatel.

Az elsődleges/egyedi kulcsok stimmelnek a táblán (az ütközés keresés az alapján megy)?

Ha jól tippelem, az első próbánál csak a - fenti példában gep nevű - "tábla-elválasztó" mező volt a kulcs: az egyezett, így minden egyes sor felülírta az előtte felvittet.
A második próbánál az Auto inc is a kulcs része lett (az kell, hogy legyen), így már ugye egyedi volt minden rekord a kulcs szerint.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( kallaics | 2015. 03. 21., szo – 21:19 )

Mi lenne ha esetleg view-t vagy temp table-ket használnál?
Akkor elég lenne 1 "táblából" lekérdezni és nem 800-ból.

Nekem ez jutott eszembe elsőre.

Azokhoz pont úgy ismernie kell a táblaneveket, és ugyanúgy le kell írnia egyszer a view definíciójában, mint a mezitlábas union használatakor.

... persze szkripttel ez is megoldható.

(Nem tudom, a mysql számára létezik-e és hol kezdődik a "túl komplex lekérdezés" hiba, ami után finomhangolni kell, de jellemzően a parasztosan egyszerű union sem ismételhető tetszőleges hosszon, akár literális, akár view-ba van rejtve.)

( KoGa v | 2015. 03. 22., v – 10:33 )

Csak kiváncsiságképp, ennek mi az értelme? Ha a tábláid szerkezetileg ugyanazok, minek kell több?

Alapesetben olyan millio rekord korul mar akar lehetne is ertelme (evente kulon tabla pl.), ugyanis MySQL-nel ugy szar a particionalas, ahogy van (foreign key eseten el is felejtheted, meg jo, hogy Postgresben pl. pont a foreign key exclusion a lenyege ugyanennek a feature-nek egy JOIN eseten). Meg ha sok az index, tobbmillio rekordnal rengeteget szamit, hogy egy update-kor hany indexet kell elrendezni.

De 3500 soros tablakbol dinamikusan uj tablakat csinalni konkretan az adatbazisszerver megeroszakolasa es abuse-olasa, aki igy gondolkodik, az jobb helyeken kiesik az elso allasinterjuforuloban. Ahol nem ejtik ki az ilyet, ott a veletlen odatevedt jo fejlesztok fognak felmondani, ha eleguk lesz a kodjabol.