08.12.2012 04:06
1
Ahoj, v databazi mám unikání sloupecek.
V tomto sloupceku je vse mozne - cisla, url adresy atd. proste bordel. ale unikatni. jinak to buhuzel navrhnout nelze.
Premyslim data prohnat nejakou hashovaci fci (md5). myslite ze to má vyznam a pomuze to nejak rychlost/vykonu databaze ?
nebo to naopak treba jeste pohorsi ?

nad touhle tabulkou pak probiha updatovaci script ktery bud vklada nova data nebo pri neunikatnosti data updatuje (ON DUPLICATE UPDATE)

díky moc.
08.12.2012 04:20
2
jsou ty unkatni data bezne prumerne delsi nez hash (md5 tedy 32 znaku)? jestli ne, nema to vyznam
08.12.2012 04:35
3
ne, nejsou.
super díky moc. já prave nevedel jestli kdyz to bude stejny format to treba nebude v necem efekivnejsi.
08.12.2012 04:38
4
u hashe je problem ze je to znakove, stejne jaky ty tvoje nahodna data, takze v tom bohuzel neni zadny rozdil, jedine bys proste mel ty data nejak ultra dlouhy, tam se pak hashovat muze vyplatit...
08.12.2012 05:06
5
Původně odeslal Re4DeR
Ahoj, v databazi mám unikání sloupecek.
V tomto sloupceku je vse mozne - cisla, url adresy atd. proste bordel. ale unikatni. jinak to buhuzel navrhnout nelze.
Premyslim data prohnat nejakou hashovaci fci (md5). myslite ze to má vyznam a pomuze to nejak rychlost/vykonu databaze ?
nebo to naopak treba jeste pohorsi ?

nad touhle tabulkou pak probiha updatovaci script ktery bud vklada nova data nebo pri neunikatnosti data updatuje (ON DUPLICATE UPDATE)

díky moc.
Pokud jsou data vždy kratší než 32 znaků, hash ničemu nepomůže. Důležité je nemít tabulku dynamickou, tedy nepoužít žádný sloupec s proměnlivou délkou (to má vliv na rychlost).


Původně odeslal Aleš Jiříček
u hashe je problem ze je to znakove
to je prosím co za výmysl? číslice není znak? nebo vy do db ukládáte veverky?
08.12.2012 05:12
6
jasně, rozumím. já si prave nebyl jist. díky

---------- Příspěvek doplněn 08.12.2012 v 05:14 ----------

Původně odeslal Jan Stejskal
Pokud jsou data vždy kratší než 32 znaků, hash ničemu nepomůže. Důležité je nemít tabulku dynamickou, tedy nepoužít žádný sloupec s proměnlivou délkou (to má vliv na rychlost).
to znamena ze je lepsi pouzivat char misto varchar ?
08.12.2012 05:14
7
Původně odeslal Jan Stejskal
to je prosím co za výmysl? číslice není znak? nebo vy do db ukládáte veverky?
ale ne, spis cisla jsem chel povazovat za integer se kterym db pracuje vyrazne ryhclej nez s VARCHAR, ale ted si uvedomuju ze hash prece neni promenlivej retezec a s CHAR db pracuje pomerne ryhcle, urcite rychlej nez s VARCHAR, ktery zcela jiste pouziva David ted, takze hash by vlastne mohl mit smysl
08.12.2012 05:17
8
no tak jsem to myslel i puvodne - že to je fixni sirka. ale to by stejne samo o sobe nic neresilo tedy?
takze by mohlo mit smysl mit char a hash? teoreticky ?
08.12.2012 10:38
9
Už je to delší dobu co jsem studoval md5, ale jestli si dobře pamatuji, tak u md5 může nastat, že se vytvoří z 2 různých řetězců stejný hash.
Pravděpodobnost bude asi hodně malá, ale kdyby to nastalo, tak se taková chyba bude hodně těžko hledat. Takže na to taky pozor.
08.12.2012 11:11
10
Jak vypadá tabulka a k čemu ten sloupec slouží?

Některé datové typy jsou obvykle delší než jiné

Multibyte Char > Singlebyte Char
Char > Binary (pro hashe)
Char > Varchar
Char > Int
Int > Enum, Tinyint
Tinyint > Bit

Porovnávání řetězců je obecně rychlejší, čím jsou řetězce kratší.

Nelze z toho ale odvozovat pevné pravidlo. Záleží vždy na konkrétních datech.
08.12.2012 12:00
11
Problém je v tom, že když A=B => hash(A)=hash(B), naopak ovšem ta implikace neplatí, tedy dva stejné heše můžou být z různých unikátních "klíčů". Dokážu si ovšem představit přidat další sloupec typu INT a do něj dávat CRC dat (taky vlastně heš), a mít nad tím index. Při dotazu pak spočítat i CRC s tím, že databáze rychle najde kandidáty, a pak porovná stringový klíč jen u jednoho/jednotek záznamů.

Jenže index je vlastně jen seřazená posloupnost v podobě stromu (typicky) a zrychlení je tedy jen takové, že místo porovnávání stringů (znak po znaku do prvního rozdílu) se porovnávají čísla (jedno porovnání). Je tedy možné, že to nic moc nezrychlí (a je možné, že to DB už interně tak i dělá).
08.12.2012 20:00
12
tabulka v sobe schraňuje data která se stahují z jiných webů a z jine databaze. a aby se neukladali duplicitne tak se prave resi unikatni klic pomoci url a id v te cizi tabulce.
08.12.2012 20:27
13
Nepíšeš moc o povaze aplikace a využití konkrétní tabulky, to je také důležité zohlednit. Způsob jaký popisuješ je v praxi standardní a nejedná-li se o o opravdu zatíženou databázi, je to řešení vyhovující.

Původně odeslal Jan Matoušek
Už je to delší dobu co jsem studoval md5, ale jestli si dobře pamatuji, tak u md5 může nastat, že se vytvoří z 2 různých řetězců stejný hash.
Pravděpodobnost bude asi hodně malá, ale kdyby to nastalo, tak se taková chyba bude hodně těžko hledat. Takže na to taky pozor.
Pokud se nejedná o nějakou aplikaci s velkým bezpečnostní rizikem, takovéhle věci je nesmyslné zohledňovat. Šance, že nastane při takovéhle práci kolize hashe dvou různých řetězců je v praxi i u MD5 v podstatě nulová.
09.12.2012 20:09
14
Když už se tu řeší unikátní sloupce, co když mám unikátní sloupec v tomto tvaru, vadí ta délka moc?

ID: cz-radio-top100-weekly-2006-01-001
...
ID: cz-radio-top100-weekly-2012-52-001
09.12.2012 20:44
15
no tabulka je to zatezovana pomerne dost :-)
09.12.2012 20:46
16
Hmmm :-\ A to je ještě ve vedlejším sloupci "chart_id" ve tvaru "cz-radio-top100-weekly-yyyy-ww", ale co už, no. Chtěl jsem to mít tak, aby bylo už z ID jasné, o co jde.
14.12.2012 16:58
17
no to moc hezke neni :D.

jeste me tak napda. dá se ze stringu nejak udelat integer? :D
nebo je to hodneissleny napad? chci to pak pouzit na provazani s jinou tabulkou pomoci treti (M:N). a nevim jestli mám vyuzit ten sloupek id ktery k tomu sice primo vybizi, ale zase se na nej musim ptat po pridani noveho zaznamu, coz mi neprijde uplne efektivni. radsi bych pouzil tenhle ktery znam uz pri pridavani zaznamu
15.12.2012 19:37
18
Zkoušel jsem si udělat crc32 hash ke stringu, samotný string (varchar řetězec) má v db nastaven unikátní klíč, sloupec s crc32 hashem má nastavený neunikátní klíč (nalézt kolizi u crc32 je jistě snazší než u md5) a jedná se o unsigned int, tedy 32bit číslo, crc32 je také 32bitový. Pokusně jsem pracoval se 150 000 záznamy. Výsledek byl ten, že pokud jsem crc32 hash použil (nejprve vypočítal crc32 stringu a na ten se pak dotazoval) nebo naopak se dotazoval rovnou na string, rychlost načítání záznamů to nijak neovlivnilo - byla stejná. Klíč jako klíč, říkám si. Nejsem si jistý, jak MySQL pracuje s indexy, ale jisté je, že index sloupce s varchar bude mít jinou paměťovou náročnost než sloupec se 4 bajtovým int. Tolik můj poznatek.

Sám jsem něco podobného použil ve své aplikaci... A asi zbytečně, pokud tedy neberu v potaz paměťovou náročnost? :)