Struktura DB pro jazykove mutace

10. 5. 2016 13:25:01

Ahoj,

mam dotaz ze skupiny zakladnich ohledne tabulek v DB.

Jak byste nejlepe vytvorili spojeni tabulky/tabulek pro nasledujici pozadavek? Bavil jste se o tom s jednim DB specialistou a pry jdu na to spatne.

Uvazuji, ze mam nazvy objektu a pro kazdou jazykovou mutaci maji samozrejme rozdilny nazev. Mutaci bude treba 30. Pro 3 objekty jako je nize, by tedy mela tabulka 90 radku.

Uvazoval jsem, ze do tabulky dam uplne vsechny zaznamy a ta tedy vypada cca takto:

loc

1 | cs-cz

2 | en-us

3 | de-de

objects

id | l id_loc | name

1 | 1 | letadlo

2 | 2 | airplane

3 | 3 | flugzeug

4 | 1 | vlak

5 | 2 | train

6 | 3 | zug

7 | 1 | loď

8 | 2 | ship

9 | 3 | schiff

Zmineny specialista ale toto reseni zamitnul a ze je standardni postup takovy, ze se do tabulky objects daji pouze hodnoty z vychozi jazykove mutace a pro ty ostatni bude slouzit tabulka objects_loc.

To znamena, ze obe tabulky by vypadaly asi takto?

loc

1 | cs-cz

2 | en-us

3 | de-de

objects

1 | 1 | letadlo

2 | 1 | vlak

3 | 1 | loď

objects_loc

1 | 2 | airplane

2 | 3 | flugzeug

3 | 2 | train

4 | 3 | zug

5 | 2 | ship

6 | 3 | schiff

Muzete mi to nekdo potvrdit? Pripadne okomentovat? Dekuji moc.

10. 5. 2016 13:25:01

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194975

Tom

(7 hodnocení)

10. 5. 2016 13:37:19

Správnější varianta je ta zmíněná specialistou. Až na to, že tabulka objects bude vypadat takto:

1 | letadlo

2 | vlak

3 | loď

Objects_loc pak bude obsahovat překlady i když budou 1:1 s objects,a le už můžou být třeba formátovány, atd.

Tam se obvykle nasypou data ve výchozí lokalizaci,ale ne aplikace, nýbrž kódu (nejspíš eng). Toliko teorie, prakticky bys to musel měřit pro tvé konkrétní použítí. Například pro vysokou zátěž (ale opravdu extrémní) by první řešení bylo vhodnější

10. 5. 2016 13:37:19

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194974

David Musil

(69 hodnocení)

10. 5. 2016 14:00:09

Ty zaznamy v budou narustat v radech tisicu pro kazdy jazyk.

Zkusim k tomu jeste neco nastudovat.

10. 5. 2016 14:00:09

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194973

indy.cz

10. 5. 2016 14:01:19

Správná varianta není ani jedna.

Takto to musi vypadat

loc

1 | cs-cz

2 | en-us

3 | de-de

objects_loc

id | lang_id | obj_id | name

1 | 1 | 1 | letadlo

2 | 2 | 1 | airplane

3 | 3 | 1 | flugzeug

4 | 1 | 2 | vlak

5 | 2 | 2 | train

6 | 3 | 2 | zug

10. 5. 2016 14:01:19

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194972

tomve

(22 hodnocení)

10. 5. 2016 14:03:54

Napsal indy.cz;1290868
Správná varianta není ani jedna.

Takto to musi vypadat
loc
1 | cs-cz
2 | en-us
3 | de-de

objects_loc
id | lang_id | obj_id | name
1 | 1 | 1 | letadlo
2 | 2 | 1 | airplane
3 | 3 | 1 | flugzeug
4 | 1 | 2 | vlak
5 | 2 | 2 | train
6 | 3 | 2 | zug

taky jsem si říkal, kde je obj_id

10. 5. 2016 14:03:54

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194971

David Musil

(69 hodnocení)

10. 5. 2016 14:28:51

Jasne, ted je mi to jasne. Diky panove.

10. 5. 2016 14:28:51

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194970

Tom

(7 hodnocení)

10. 5. 2016 14:37:07

Napsal Tomve;1290870
taky jsem si říkal, kde je obj_id

Pravda, to jsem přehlédl

10. 5. 2016 14:37:07

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194969

(20 hodnocení)

11. 5. 2016 15:11:28

Napsal indy.cz;1290868
objects_loc
id | lang_id | obj_id | name
1 | 1 | 1 | letadlo
2 | 2 | 1 | airplane
3 | 3 | 1 | flugzeug
4 | 1 | 2 | vlak
5 | 2 | 2 | train
6 | 3 | 2 | zug

proc je tam sloupec id? pro jendoznacknou identifikaci radku a zaroven zabraneni duplicit prece staci lang_id, obj_id takze primary key z techto dvou sloupcu a id vubec nepouzit... Tenhle nesvar je az nechutne rozsireny, poslednich par aplikaci co sem mel tu cest opravovat melo uplne stejnou blbost v db

11. 5. 2016 15:11:28

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194968

qwertr

(7 hodnocení)

11. 5. 2016 15:29:06

Preco to vadi ? Predpokladam ze to porusuje nejaku normalovu formu. Ovplyvni to vykonnost databazy alebo ake ine vplivy to bude mat.

A teraz ti poviem, proco ja by som dal tiez tak isto slpec ID.

Foreign key. V dalsich tabulkach nemusim mat dva stlpce, ale staci mi jeden stlpec na ID.

Pisanie aplikacii. Teraz mam aplikaciu, kde som do jednej tabulky nevytvoril ID ale nechal zlozeny primarny kluc.

Teraz vsade, ked potrebujem pristupovat k zaznamu pomocou primarneho kluca, vsade v aplikacii si musim pametat dve hodnoty nemiesto jednej.

11. 5. 2016 15:29:06

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194967

(20 hodnocení)

11. 5. 2016 15:37:24

Pokud mas zaznam v db ktery ma jako primarni klic dva sloupce, je prakticky jiste ze v aplikaci k tomu zanamu pristupujes az kdyz vis proc a jake hdnoty v tech sloupcich jsou, pokud tot ak neni a pristupujes k tomu zaznamu v miste kde ty hodnoty nemas automaticky a musis je nejak slozite ukladat ci je hledat, tak je nekde chyba v tvem navrhu (db nebo aplikace) nedokazu si predstavit jediny pripad kdy by pouziti sloupce ID v tomto pripade bylo spravne a ten sloupec tam zkratka nebyl zbytecne navic... :) Neni to vylsovene spatne a neni to vyslovene hruzostrasna chyba, ale neni jediny realny duvod to tam mit...

11. 5. 2016 15:37:24

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194966

indy.cz

11. 5. 2016 16:10:10

Ano to je pravda, ze ta db neni v normalizovanem tvaru, ale zase co znam aplikacni frameworky, tak hodne z nich ma na adresovani a upravy zaznamu jedno jedinecne ID - napr. Eloquent - mozna to jde nekde nastavit, nevim. Kde to vylozene vadi jsou ciste spojovaci tabulky pro M:N relace.

11. 5. 2016 16:10:10

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194965

(20 hodnocení)

11. 5. 2016 16:19:56

Obecne mi nevadi ze si ve svoji aplikaci nekde lidi masti praseciny, delam to uplne stejen kdyz delam neco pro sebe a proste potrebuju jen aby to nejak fungovalo... Delat to ale pro zakazniky nebo to radit na foru... :)

A vymluva na to ze to nejaky system neumi je licha. Budto to ten system umi a vy ho timpadem spatne pouzivate a nebo to neumi a zaslouzi si byt v kosi a ne v produkci :) A docela me prekvapuje kolik vcelku jako rozsirenych projektu je opravdu takto postizena... Jak rikam, neni to velka chyba a neni to neoc co vyslovene vadi, jen je to proste vec, ktera svym zpusobem neni spravne a je to berlicka pro system co neni dobre navrzeny

11. 5. 2016 16:19:56

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194964

indy.cz

11. 5. 2016 16:32:38

Normalizace DB je volitelná záležitost při kterém je samozřejmě snaha mít nejnormálnější formu, ale není to vždy optimální. A abych vyhazoval FW do kose, to tam radeji vyhodim Vas akademicky nazor ;-)

11. 5. 2016 16:32:38

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194963

(20 hodnocení)

11. 5. 2016 16:37:46

muj nazor neni akademicky... Nekde to dava absolutne smysl, ale nedava to smysl pokud to delame jen proto, ze s tim neumime pracovat v aplikaci (nebo nekdo v Laravelu neumel napsat tak zakladni fcnost jako je tohle), o nic vic tu nejde, treba v tomhle konkretnim pripade o kterem se tu bavime ted tady v tomhle tematu je proste sloupec id absolutne redundantni

11. 5. 2016 16:37:46

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194962

indy.cz

11. 5. 2016 16:43:39

Jenze pokud prepisete standardni chovani Laravelu, tak tam vnesete funkcionalitu navic o kterou se taky musi nekdo starat, dalsi vyvojar studovat, ze to mate v datove tabulce takto a vnesete do aplikace dalsi uroven komplexnosti, protoze misto jedne promenne pri uprave zaznamu v datove tabulce tam mate dve promenne a jinde pri uprave Datove tabulky tam mate jednu. Ale od zacatku s Vami souhlasim, ze ty tabulky nejsou v normalnim stavu. Ale to neni modla. Diskovy prostor neni jediny zdroj ktery pocitate.

11. 5. 2016 16:43:39

https://webtrh.cz/diskuse/struktura-db-pro-jazykove-mutace/#reply1194961