MySQL INSERT do více tabulek? Hromadný?*

dá se to nějak řešit v mysql5? největší problém mi dělá hromadný insert, jinak bych samozřejmě použil last_insert_id a do dalších tabulek vkládal s nastaveným id, ale co když jde o složený insert

table
id PRIMARY AUTO_INCREMENT
desc TEXT

INSERT INTO table (desc) VALUES ("ahoj"), ("nazdar")

no a nejhorsi je ze bych to potreboval vlozit jeste do druhe tabulky ale s vazbou na primarni klice

table2
id PRIMARY AUTO_INCREMENT
meta TEXT

INSERT INTO table2 (meta) VALUES ("nějaké meta k ahoj ale nevím jaký mám primaryID"), ("nějaké meta k nazdar ale nevím s jakým ID protože mezi tím už mohl někdo vložit další záznam a primary id by nesouhlasilo")


Díky všem za tipy a rady

15000 záznamů??

takovou transakci si může dovolit jen málokterý web, zvlášť když celková velikost je 20mb což může být hodně dlouho

2 minutky nejsou zrovna málo konkrétně je to na 3.43 minutky na hodně výkonném stroji, za ty dvě minutky ovšem může přibýt pár záznamů o které bych přišel a to si také nemůžu dovolit, jinak mysql jestli se nemýlím tak postupuje podle popsaného schématu, vloží nejdříve jinam a pak přejmenuje na tu samou tabulku? tak nevím jestli je důležité zda je to živá databáze nebo ne? třeba se mýlím


použít jednu tabulku nelze, právě jsem to raději rozsypal do deseti, ono 100 sloupců není asi úplně košér nehledě na to, že při většině dotazů se nebudou číst všechny údaje a proto není nutné projíždět tabulkou o velikosti 100MB ale dle mého je lepší selectovat tabulku o 1MB a k tomu připojit věc kterou zrovna v tom dotazu chci z jedné z dalších tabulek o velikosti 20MB ?? proto je to rozsipané na více tabulek

To proč to nehcci dělat po jednom jen, že nikdy dopředu nevím kolik záznamů se bude zpracovávat někdy 100 někdy 1000, při té stovce by to chtělo celkem svižnou odezvu.


A pak tady mám jednu situaci kdy je nutné mít v jiné tabulce párový klíč právě vloženého záznamu, takže:

1. tabulek musí být více je proto spousty důvodů
2. akce může mít hodně záznamů nebo málo, může být částá nebo jednou za den

A mimochodem, nějak ti blbne klávesnice — omylem ti píše velkými písmeny; zkus na to mrknout, asi blbne Caps lock.


záleží na tom??? nechápu, ale to asi nevadí

1. provázání souhlasí
vztah 1:1

2. bez autoincrementu tak nějak nevím kde vzít to id?

table1
id PRIMARY
config1 TINYINT(1)
config2 TINYINT(1)
config3 TINYINT(1)
config4 TINYINT(1)
config5 TINYINT(1)

table2
id PRIMARY
text TEXT
text1 TEXT
text2 TEXT

table3
id PRIMARY
name VARCHAR
name2 VARCHAR
name3 VARCHAR


kazdý záznam do tabulky table1 se musí projevit i v table2 a table3

mám sadu záznamů pro zjednodušení např v csv

soubor table1.csv
radek - config1;config2;config3;config4;config5
radek - config1;config2;config3;config4;config5
radek - config1;config2;config3;config4;config5
radek - config1;config2;config3;config4;config5

soubor table2.csv
radek - text1;text2;text3
radek - text1;text2;text3
radek - text1;text2;text3
radek - text1;text2;text3

soubor table3.csv
radek - name1;name2;name3
radek - name1;name2;name3
radek - name1;name2;name3
radek - name1;name2;name3


a tyhle csv soubory potrebuji nasypat do dtb a radky samozrejme mezi sebou provazane


je to jen priklad ted vymysleny pro pochopeni treba to neni uplne stastne

DÍKY VŠEM ZA TIPY A RADY

sory, vadí ti to hodně?? není to zbytečná buzerace? pripadá mi 5 příspěvků kvůli 6 slovům napsaným capslockem jako porušení pravidel a jestli to není tak by mělo být, protože to mě spíš štve víc, je tady zbytečný balast


1. dělat v noci to nelze, dělat se to musí kdy je potřeba (ať už jakkoli přesun v čase neřeší problém)
2.
Zkoušels do těch insertů dát něco ve smyslu: INSERT INTO table2(meta) VALUES((SELECT id FROM table WHERE desc='ahoj'), ...?

neřeší problém spíš vytváří nový, 15000 insertů a dalších 15000 selectů a dalších 15000 insertů pro každou table mě nepřijde jako dobrý nápad, description je vždy jiný samozřejmě anebo také stejný

1. dejme tomu ze to jsou importy dá se to tak specifikovat

jinak sory jestli jsem v predchozi diskusi tykal jsem na to zvykli z diskusi stejne nikdy nevim s kym se opravdu bavim, pokud to neni problem navrhuji

LOAD DATA využívám, ale to není podstatné, integrita je a pořádí řádků je zaručeno, tabulka kde je vše je vytvořena a úspěšně funguje, ovšem jsme zpět na stejném problému

mám jednu tabulku a potřebuji z ní přesunout data do 5 jiných tabulek, ve kterých se tyto data vytvářejí a jsou navzájem provázány unikátním id, které ovšem je logicky známé až po vložení do hlavní tabulky a to je problém,

tak jinak mám tabulku s těmito daty


name descr config1 config2
ahoj textahoj 1 2
nazdar textnazdar 3 4
...................................................................... .dalších 15000 řádků - probíhá to třeba 10x denně, opravdu potřebuji řešit hlavní problém než to pouštět v noci apod. to mi nepomůže



no a tento soubor nebo tabulku to už je jedno, umím si csv nasypat do tabulky, nebo tabulku vytvořit apod., potřebuji nasypat do tří tabulek

nejprve vložit do

table1
confi1, config2

po vložení se vytvoří id, takže bude v table1

např.

15000 záznamů


id config1 config2
891231313 1 2
891231314 5 2
891231315 1 2
891231316 3 2

atd. atd.

no a ja potřebuji k těmto id vytvořeným ještě uložit ty name a descr.

jak jsem psal tabulek je více a zůstane více, nelze spravovat tabulku o 100 sloupcích a velikosti 100MB, rychlost při 5000 návštěvnících už je pak dost znatelná když se provádí selecty z této tabulky

no ano chapu takze to je ale zpracovani

15000 radku

kazdy po jednom a nejakych ted uz se v tom ztracim 13minut mi to dalo je proste moc, musi se to delat live na live datech a v nejnavstevovanejsich hodinach proste jinak to opravdu nejde data musi byt aktualni a hlavne clovek co to zpravuje proste u toho v noci sedet nebude


tohle snad uz objasni o co mi jde:

obrázek:


sql:
http://www.nhlpro.cz/webfaq/insertIntoMoreTables.sql

z toho temptable potrebuji nasypat data do tech ostatních tabulek (řeším to jedním způsobem, který sem tady nechtěl říkat abych neodvedl konverzaci jinam, ale je velice neštastný tak se ptám jestli to lze řešit nějak šťastně)

už jsem to psal v tomto vláknu,

tabulka má 100 sloupců a 100MB

při většině selectů není potřeba procházet celý takto velký soubor, ale je potřeba filtrovat jen v tabulce

table1 která po rozdělení má asi 1MB a pak uz si vyberu tabulku kterou joinnu, takze mi pripada prochazet table 1MB a z toho vybrat relevantni radky ktere se joinnou na tabulku o 10MB lepsi nez prochazet cely 100MB soubor nehlede na to ze to proste neustale roste a roste jak do sloupcu tak do velikosti a slibuju si u toho prospech z rozdeleni

nehlede na to ze nektere objekty pouzivane v ruznych projektech umi pracovat jen s urcitou tabulkou a zmeny v ni nejsou bohuzel mozne, proto je snadnejsi upravovat tabulky ostatni, neli jedina moznost

Ale jak jsem psal tím bych se nezabýval, jde tady o úplně jiný problém, píšu to v každém druhém příspěvku, problém je jinde, tento problém se jistě vyskytne ve více příkladech a situacích

no to mne napadlo jednak je problem ze

temptable se maze prubezne a znovu plni
takze vzdy bude id zacinat od 1

zato ostatni tabulky maji id uz treba na 1000,

krom toho se bojim ze uprostred tohoto celeho zpracovani mi tam nekdo neco vlozi a tim posune id, nevim jak je to se zamykanim tabulek na mysql5 a innodb?? jde cist z te tabulky nebo nedela to problem, co kdyz klekne skript, tabulka zustane zamcena???

nekde jsem cetl ze je s tim problem.

a hlavne bojim se integrity pri takovem zpracovani co kdyz jeden radek se nevlozi?a tim posune vsechna id co se maji vkladat do ostatnbich tabulek

je to proste pro ilustraci, ta pomocna tabulka da se vytvorit to neni problem, je to tak jak jsem zobrazil na obrazku, v temptable coz je temporary table jsou zaznamy a ty se neustale meni, mazou a pribyvaji, a ja je vzdy jen potrebuji rozsypat do tech tri tabulek

1. to je současný stav, rychlost dtb je opravdu dramatická

2. to opravdu nechci opět problém s rychlostí

3. popisovaný způsob používám také v jiném smyslu, to jeto řešení co jsem nechtěl říkat, ale moc se mi nelíbí

problém je, že nevím jestli je rozumné u tak velké tabulky s 100tky tísíc selectu denně provádět live ALTER TABLE a přidávat pomocný sloupec, je tady ta možnost ho tam nechat což podotkl tiso, ale zase je tady ten problem ze temp tablu je desitky a kazdy ma svoje id, to sem take nechtel rikat protoze uz je to moc slozite, takze dosud vzdy pri hromadnem importu vytvarim temporaryID sloupec a pomoci neho pak uz mohu sypat data do jinych tabulek, v pripade 100 temp tablu bych musel ale vytvorit 100 temporaryID a to se mi take moc nelibi


takze problemy
1. za behu pri velice pouzivane tabulce provadet ALTER TABLE nevim jestli je moudre
2. mit 100 parovych sloupcu a mohou rust zase zalezi na adminovi jak se k tomu postavi ale 100 a 200 sloupcu neni neobvykle, nevim jestli je to dobre takto rozsahla tabulka hlavne kdyz ten pocet sloupcu proste nastavuje nekdo z adminu tim ze vytvori novy temp table ktery zpracovava data odjinud, tak nevim

uz jsem premyslel i o postgre ale nemam zkusenosti

proc je 100 temp tablu bych take nerozebiral, jde o ruzne statistiky hokeje z ruznych zdroju, neustale updatovanych apod. vysvetleni by bylo slozitejsi nez cele tohle vlakno, proste tim bych se nezabyval opravdu jsou nutne ty dalsi temptable