Autor Zpráva
matak
Profil
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
Kajman_
Profil *
Tak to ukládejte po jednom.
matak
Profil
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
Aesir
Profil
matak
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


Takovou transakci nad živou databází si může dovolit jen málokterý správce. Prostě udělat druhou db, do té to nacpat data nějakým skriptem, poté odříznout nad webserverem na chvíli lid zvenku a zreplikovat data do živé db, to už bude na cvhíli.
djlj
Profil
Vždyť to je tak za 2 minutky hotový.

A pokud je struktura taková, jakou popisuješ, možná by bylo vhodnější použít jedinou tabulku.

A mimochodem, nějak ti blbne klávesnice — omylem ti píše velkými písmeny; zkus na to mrknout, asi blbne Caps lock.
matak
Profil
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
matak
Profil
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í
Aesir
Profil
matak
Chápu správně, že table2 je provázána na table1 přes sloupec id? Jestli ano, tak potom nechápu auto_increment u jedné z těchto tabulek.
Řešil bych to insertem, který mi vygeneruje nějaký skript z dat, jak jsem již psal výše, tedy něco jako:
INSERT INTO table (id, value) VALUES (id1, value1), (id2, value2) ...

a druhou tabulku naplníte stejným způsobem s tím, že můžete použít pro spojení vnořený select.

Pokud to stále nechápu, tak ať raději poradí někdo jiný, nebo mi to nakreslete :P
djlj
Profil
matak
Zkus si pro příště pročíst sekci závazná pravidla. (A to pomíjím, že text psaný caps lockem vyznívá dost dementně.)

Zkoušels do těch insertů dát něco ve smyslu: INSERT INTO table2(meta) VALUES((SELECT id FROM table WHERE desc='ahoj'), ...?

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
Dělej to v noci.

Aesir
Taky to nechápu :).
matak
Profil
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
matak
Profil
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ý
Aesir
Profil
matak

Takže se jedná o jakésy pravidelné importy, jest tak?

Jak jsou provázány mezi sebou jednotlivé řádky mezi csv soubory? Spoléháte na správné pořadí řádků a v databázi na autoinkrementální sloupec? Pokud ano, tak pozor na integritu dat, je to docela hazard.

Pokud to chcete nahrávat soubor po souboru, tak můžete využít LOAD DATA a spoléhat na zámek tabulek.

Pokud to chcete udělat pořádně, předělejte impot do jednoho souboru, kde jeden řádek bude jeden záznam s jedinečným identifikátorem. Soubor pak ve skriptu parsujte řádek po řádku a data si rozházejte do libovolných tabulek, propojených právě tím jediným a jedinečným identifikátorem.
matak
Profil
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.
Kajman_
Profil *
vztah 1:1

Proč si tedy neuděláte jednu tabulku. Stačí číst ty tři soubory a vytvářet si jeden insert. (Ale stejně bych to osobně řešil přes více insertů.)
matak
Profil
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
Kajman_
Profil *
Tak si je dejte do pracovní tabulky a z ní to rozházejte do ostatních. Jedním insertem prostě do více tabulek data nedáte.
Aesir
Profil
matak
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

To přece nemusí být pravda, pokud si exportujete data i s unikátním ID, které je v této počáteční jedné tabulce, provažte data ve třech nebo pěti tabulkách (nebo kolik jich vlastně je) přes toto ID.
Tedy exportujte počáteční tabulku do jednoho souboru, ať už cvs nebo xml a ten pak parsujte skriptem řádek po řádku a šoupejte data kam potřebujete, už to navrhuji minimálně potřetí ;)
matak
Profil
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ě)
tiso
Profil
Nechápem dôvod takéhoto rozdelenia tabuliek so vzťahom 1:1... Prečo máš 2 indexy (id i Table_01_id) v tabuľkách 2 a 3?
matak
Profil
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
tiso
Profil
matak - aha, prečo nie takto: využiť idtem_table ako index, na tabuľkách 1, 2, 3 zrušiť AUTO_INCREMENT na id a vložiť ich tam priamo, po transakcii obnoviť AUTO_INCREMENT (treba nastaviť hodnotu od ktorej má rátať na MAX(idtemp_table)
matak
Profil
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.
matak
Profil
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
tiso
Profil
Ty vkladáš záznamy do temp_table a zobrazuješ ich z tabuliek 1, 2, 3? Alebo ako?
matak
Profil
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
Kajman_
Profil *
Myslím, že máte jen dvě varinaty a obě odmítáte...

1. dát to do jedné tabulky (a aplikacím, které vyžadují jen určité sloupečky třeba udělat view s původním názvem)

2. dělat alespoň do první tabulky insert po jednom řádku (což můžete i v uložené proceduře)

Možná by ještě šlo přidat do první tabulky pomocný sloupec odkazující se na id z pomocné tabulky a třeba trigger by při insertu takového řádku naopak vložil získané id do pomocného sloupečku v pomocné tabulkce, takže do dalších tabulek by šlo použít klasické insert into... select.
matak
Profil
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
matak
Profil
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

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: