Struktura DB pro jazykove mutace

11. 5. 2016 16:50:07

Osobně mám rádši, když každý záznam má unikátní ID, které nelze změnit.

Lang_id a obj_id lze změnit, pokud se BFÚ sekne, BFÚ spíš bude editovat záznam než mazat a dělat nový. Sice update prvně vyhledá, a pak změní, ale i tak, je mi to proti srsti.

11. 5. 2016 16:50:07

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/strana/2/#reply1194960

Fido123

(13 hodnocení)

11. 5. 2016 16:50:43

Napsal indy.cz;1291239
Diskovy prostor neni jediny zdroj ktery pocitate.

Tady nejde pouze o místo na disku, ale taky o výkon. Takhle bude třeba udržovat dva unikátní indexy místo jednoho, což sebou samozřejmě nese nějakou režii.

11. 5. 2016 16:50:43

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/strana/2/#reply1194959

TomasX

(4 hodnocení)

11. 5. 2016 16:55:54

ano, také mi občas vstávají vlasy hrůzou, když to vidím všude, dnes to je již přežitek. Začal jsem programovat v době, kdy podpora v hybernate, phpmyadmin či postgres byla děsivá. Dnes composite primary key umí i doctrine a pokud to vyloženě není technická nutnost, do návrhu databáze nepatří.

Pro composite key mluví:

- neduplikuji data

- nezesložiťuji struktury v databázi a nechávám jí tak jednoduchou, jak jde

- rychlejší zápis

Proti mluví:

- primární index zabírá dvojnásobek místa (v malém počtu záznamů nevadí)

- stránkovat musím přes limit, offset a nikoliv ID range

- podpora ve frameworcích byla donedávna slabá (vč. phpmyadmin)

- práce s více řádky není determistická a snadno může dojít k chybě (proto i podpora ve frameworcích nebyla hned)

11. 5. 2016 16:55:54

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/strana/2/#reply1194958

indy.cz

11. 5. 2016 21:11:16

TomášX - jen malé upozornění, primární index v běžných tabulkách nezabírá žádné místo navíc, i kdyby byl třeba přes 50 sloupců. Je to prostě fyzické uspořádání dat v tabulce - b-tree. A stránkovat musím přes limit a offset také skoro vždy, protože tam budou díry po smazaných záznamech. Ale jinak souhlasím!

11. 5. 2016 21:11:16

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/strana/2/#reply1194957

TomasX

(4 hodnocení)

11. 5. 2016 21:30:56

index samozřejmě místo zabírá (ve všech běžných relačních databázích, neberu v úvahu exoty jako hbase) a je rozdíl pokud indexuji jeden nebo dva sloupce. Ano, u malých tabulek a běžných projektů to nepoznáš a je to jedno, ale jakmile potřebuješ nacpat celý index do operační paměti a máš GB a více dat, musíš to zohledňovat. Data v třeba mysql databázi jsou uložena v jiné struktuře než samotné indexy, ukládat data v b-tree by bylo hooodně nehospodárné.

Limit a offset jsou strašně pomalé pokud chci stránkovat k posledním stránkám - záznamy se musí načíst a pak zahodit - naopak se běžně používá něco ve stylu ID > last_visit_id LIMIT 30, což je odolné proti smazaným záznamům

11. 5. 2016 21:30:56

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/strana/2/#reply1194956

indy.cz

11. 5. 2016 21:55:28

Primární index místo nezabírá. V mysql jsou právě data uložena v clustered indexu - což je primary index nebo první unique po ruce. Takže místo nezabírá. I v jiných DB je to velice podobné. Dělat to jinak by bylo HOOOOOOODNE nehospodarne

---------- Příspěvek doplněn 11.05.2016 v 21:58 ----------

Protože když DB stroj hrábne do primary indexu tak už má celý row = DATA !!!!

---------- Příspěvek doplněn 11.05.2016 v 21:59 ----------

Až sekundární indexy jsou samostatně

---------- Příspěvek doplněn 11.05.2016 v 22:08 ----------

MYSQL doc:

How the Clustered Index Speeds Up Queries

Accessing a row through the clustered index is fast because the index search leads directly to the page with all the row data. If a table is large, the clustered index architecture often saves a disk I/O operation when compared to storage organizations that store row data using a different page from the index record. (For example, MyISAM uses one file for data rows and another for index records.)

11. 5. 2016 21:55:28

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/strana/2/#reply1194955

TomasX

(4 hodnocení)

11. 5. 2016 22:18:11

ok, máš pravdu, mluvíš o innodb, já o myisam, což už je minulost. Jasně, clustered index, úplně jsem na něj a na tyhle suproviny v innodb zapomněl, ano, data jsou ve stejné page jako index, v tom jsem mýlil.

Ano, clustered index je velice nehospodárný, extrémně drahý na update a zabírá mnoho, mnoho místa navíc. Je ale extrémně rychlý pro čtení, nemusím dělat další look up v paměti, vše mám s indexem vedle sebe, už si vzpomínám :).

11. 5. 2016 22:18:11

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/strana/2/#reply1194954