Autor Zpráva
JardaB
Profil
Potřebuji přesunout data z jedné tabulky do druhé, kdy klíče ID chci vynechat, protože mohou být stejné, byť třeba jen v jednom záznamu a chci aby byly automaticky přiřazeny po zkopírování nové, o což by se mělo postarat AUTO_INCREMENT

tento zápis to vykoná, pokud nedojde ke shodě ID

insert into `tabulka2` select * from `tabulka1`

chápu, že je asi nutné tedy vyjmenovat veškeré sloupce a vynechat ID, neexistuje však zápis, který řekne, zkopíruj vše, jen vynechej ID?

Ještě dotaz, je nějak možné, když mám nastaveno AUTO_INCREMENT, aby se hodnoty nepřiřazovaly vždy o jedno vyšší než je hodnota nejvyššího ID, ale aby se přiřadila automaticky hodnota ID nějakého již promazaného záznamu? Případně jak se to dá řešit? Nerad bych měl za čas ID hodnoty v řádech 10M
jenikkozak
Profil
Odkážu na odpověď na druhý dotaz. Možná to vyřeší i první otázku.
JardaB
Profil
ID mám jediný možný unikátní identifikátor mých položek, přes který na položky odkazuji. Zbytek jsou jen textové řetězce nebo hodnoty upřesňující charakter produktu. Pokud jsem dobře pochopil, je vhodné se použití ID vyhnout a mám vyřešeno? Jak budu tedy odkazovat na produkt? Když v tabulce může být desítky produktů stejného charakteru, nehledě na to, že nějaký klíč být musí. Nepotřebuji měnit klíče existujících položek, ale zabrat volné klíče a přiřadit nově příchozím položkám. Ono jde o to, že data klientů se rychle mění a tedy je musím načítat každý den, kdy se jedná cca o 2M položek, kdy sice s touto hodnotou datový typ BIGINT jen tak nevyčerpám, ale nehrozí mi teoreticky se změnou na tento datový typ větší zátěž serveru?
ts_istudio
Profil
JardaB:
Ještě bych dodal, že i přesun dat z tabulky do tabulky bude zřejmě chybou ve smyslu špatného návrhu aplikace. Když napíšeš, čeho se snažíš dosáhnout, skoro určitě ti ten postup někdo rozmluví a navrhne lepší.

Nepotřebuji měnit klíče existujících položek, ale zabrat volné klíče a přiřadit nově příchozím položkám.

Za volné klíče nepovažuj ta ID, která už někdy existovala a byla smazána.

nehrozí mi teoreticky se změnou na tento datový typ větší zátěž serveru?

Ne.

Pokud jsem dobře pochopil, je vhodné se použití ID vyhnout a mám vyřešeno?

Ne. ID používej, ale nesnaž se s ním nijak manipulovat. Žádné přepisování, žádné vyhledávání "volných pozic".
JardaB
Profil
ts_istudio:
Přesun dat z tabulky do tabulky vysvětlím.
V hlavní tabulce jsou data všech produktů cca 2M, později i více. Když načítám nové položky, načtu je do pomocné tabulky se stejnou strukturou, zde s nimi pracuji (kategorizuji), jakmile tento proces dokončím, přesunu do hlavní. Řekl bych, že když bych pracoval s daty v přímo v hlavní tabulce o 2M položkách, tak tomu dám záhul. Kdežto v pomocné tabulce pracuji pouze s cca 1-50 tis položkami max. Pokud vás napadá jiný způsob zpracování, rád si nechám poradit.

ID nepotřebuji měnit ani vyhledávat volné pozice.. šlo mi jen o to, abych nevyčerpal datový typ, abych nemusel na něco takového myslet nebo nebyla tímto ta aplikace omezena. Jiná myšlenka v tom nebyla.
ts_istudio
Profil
JardaB:
V hlavní tabulce jsou data všech produktů cca 2M, později i více. Když načítám nové položky, načtu je do pomocné tabulky se stejnou strukturou, zde s nimi pracuji (kategorizuji), jakmile tento proces dokončím, přesunu do hlavní. Řekl bych, že když bych pracoval s daty v přímo v hlavní tabulce o 2M položkách, tak tomu dám záhul. Kdežto v pomocné tabulce pracuji pouze s cca 1-50 tis položkami max. Pokud vás napadá jiný způsob zpracování, rád si nechám poradit.

Nevím, co přesně obnáší ta kategorizace. Nejspíš bych ty položky dával rovnou do té ostré tabulky a měl bych tam i sloupec "zobrazovat" - INT(1) a podle něj rozlišoval, co je ve stadiu zpracování a co je zpracováno. Co ta kategorizace znamená, to je nejspíš to podstatné.
JardaB
Profil
ts_istudio:
Mno :D

tohle jsem měl uděláno původně.. proces kategorizace 50 tis položek mám sice rozdělen do dávek po 5 tis... ale jakmile tohle provádím přímo v tabulce s 2M produkty, tak je délka zpracování cca o 20% více. Jde o to vzít jednotlivý nový záznam a porovnat s cca 2 tis záznamy kategorizační struktury, přiřadit kategorii a provést modifikaci záznamu. Mé řešení mi přijde celkem rozumné, kdy navíc pracuji se surovými daty na bezpečnějším místě. Nebo je snad někdo názoru, že pokud je dobře navržená struktura tabulky a aplikace k nim správně přistupuje, tak její kapacita neovlivní zásadně dobu dotazů? V současné době při 2M položkách má cca 1.5 GB dat.
ts_istudio
Profil
JardaB:
Nebo je snad někdo názoru, že pokud je dobře navržená struktura tabulky a aplikace k nim správně přistupuje, tak její kapacita neovlivní zásadně dobu dotazů?

Tvou aplikaci neznám, ale v zásadě to tak nějak je. A jestli to všechno děláš proto, abys ušetřil 20 % času, myslím, že ta úspora bude vypadat jinak, když si započítáš právě ty tanečky kolem toho extra zpracování, dodatečného připojování atd. Ale to už jen odhaduju.
JardaB
Profil
:D mno já se snažím tak trochu myslet i na zátěž, tedy když se něco vykonává déle, tak to i zabírá místo dalším procesům. Navíc těch 20% delšího času relativně snazší metodou je oproti již kompletní délce zpracování včetně těch tanečků jak tomu říkáš.. Pokud nepřijdu na o něco efektivnější možnost, tak to asi ponechám jak je... uvidíme co to udělá při dvojnásobku položek.

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: