Prodej projektu Duchod.cz - cena 550 tis Kč. Dále MojeFinance.cz, DuchodovaReforma.cz
Zobrazují se odpovědi 1 až 22 z 22

Struktura DB pro jazykove mutace

  1. 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.

  2. Co se právě děje na Webtrhu?
    JJprojekty poptává: Vytvoření velmi jednoduchého eshopu
    Lukas.8.2 poptává: Vytvoření ehopu
    Hustosef poptává: Front-end developer externě (Praha)
  3. 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ší

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

    Zkusim k tomu jeste neco nastudovat.

  5. 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

  6. Citace Původně odeslal indy.cz Zobrazit příspěvek
    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

  7. Jasne, ted je mi to jasne. Diky panove.

  8. Citace Původně odeslal Tomve Zobrazit příspěvek
    taky jsem si říkal, kde je obj_id
    Pravda, to jsem přehlédl

  9. Citace Původně odeslal indy.cz Zobrazit příspěvek
    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

  10. 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. 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...

  12. 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.

  13. 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

  14. 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 ;-)

  15. 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

  16. 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.

  17. 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.

  18. Citace Původně odeslal indy.cz Zobrazit příspěvek
    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.

  19. 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)
    Naposledy upravil TomášX : 11.05.2016 v 18:25

  20. 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!

  21. 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

  22. 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.)

  23. 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 :).

Hostujeme u Server powered by TELE3