Diskuze: Návrh databáze pro vícejazyčné záznamy

Aktivity

Uživatel sítě

Tvůrce

Uživatel sítě :24.7.2019 15:49

Zdravím,

rád bych znal váš názor na návrh databáze pro uložení překladů záznamů v ní.

Z hlavy mě napadlo řešení, které bych přirovnal k Překlady v samostatné tabulce v tomto článku od Kuby Vrány:
https://php.vrana.cz/…-zaznamu.php

Nedalo mi to a dneska jsem se začal trošku zajímat jestli nejsou i jiné (elegantnější) návrhy a jak jsem se dozvěděl z výše zmíněného článku, tak možností je spousta (i když, už né tak elegantní, jak se na první pohled zdá).

Sám Kuba doporučuje poslední uvedené řešení, tedy překlady přímo do tabulky s daty, pro které je překlad určen.

Samozřejmě za to sklidil velký hate v diskusi, v tabulce to sice nevypadá tak elegantně jako 1. způsob, ale SQL dotazy už vypadají o mnoho lépe.

Co vy? K jaký přístup by jste zvolili vy a proč?

Btw:
V mém případě bych ideální řešení použil pro klasický eshop o tisících produktech.

Díky.

Editováno 24.7.2019 15:49

Odpovědět

24.7.2019 15:49

Chybami se člověk učí, běžte se učit jinam!

NouF

Člen

NouF:24.7.2019 19:21

Ahoj, ten článek je z roku 2009. Asi se ti ted pod to nepodepíše. Já bych mrknul na novodobé frameworky a tam se inspiroval, pokud nechci to opravdu hrotit a vymyšlet nové řešení.

Nahoru Odpovědět

24.7.2019 19:21

Uživatel sítě

Tvůrce

Uživatel sítě :24.7.2019 22:35

Ahoj,

mno to řešení, které tam doporučuje se nejspíše hodí pro menší blog či shop o desítkách produktech? Využití by v dnešní době možná ještě našlo. Ale železo v dnešní době je také trošičku na jiné úrovni..

Zase ta verze, kterou mám nyní vypadá přeci jenom elegantněji, avšak ty SQL kódy jsou opravdu šílenost na první pohled..

Ale jak už to bývá, každá verze má své pro i proti, to je jasné.

Každopádně díky ti za reakci, uvidím zda se ještě někdo přidá, popřípadě doporučí jiné řešení?

Nahoru Odpovědět

24.7.2019 22:35

Chybami se člověk učí, běžte se učit jinam!

don.jarducius

Člen

don.jarducius:25.7.2019 8:58

Ahoj,
tak je to celkem jednoduché. Vezmu to na té stránce od konce... Dotazy jsou všechny velmi velmi jednoduché

Překlad přímo v tabulce s daty: Když přidáš další jazyk, musíš upravit spoustu věcí v kódu aplikace, tzn. vždy potřebuješ programátora a ten bude mít spoustu práce. To samé pokud přidáš podporu více měn.
Kopie dat i překlady v samostatné tabulce: Toto už je lepší z hlediska dynamičnosti, nicméně stále jen neřeší vše a je velmi nedomyšlené... - Tento styl řešení se ale reálně používá

Podle celého článku bych ti moc nedoporučoval vycházet z jeho návrhů.
Např. nevidím jediný důvod neustále joinovat proti tabulce jazyků... Jazyk volíš v aplikaci a tudíž si tam pamatuješ i ID.
Dál třeba jeho argument že se jazyk přidává jednou za dlouhou dobu je právě jedno z úskalí... Kdo si po té době bude pamatovat, co se kde v kódu muselo... a pak to dost často končí přepsáním velké části aplikace protože už si zkrátka nikdo nepamatuje jak to bylo. -> Autor evidentně dělá jednorázové amatérské aplikace bez supportu pro velmi malé zákazníky... větší zákazník nikdy nepřijme takové řešení.

Dnešní servery mají spoustu výkonu a SQL databáze mají takových optimalizací, že rozdíl mezi vyhodnocením dotazů bude u shopů s 10 000+ produkty pouze v jednotkách milisekund.

Editováno 25.7.2019 8:59

Nahoru Odpovědět

25.7.2019 8:58

Ten kdo nechce hledá důvod, ten kdo chce hledá způsob

Uživatel sítě

Tvůrce

Uživatel sítě :25.7.2019 9:03

Ahoj,

velice plodná reakce, děkuji ti za ni.

Nahoru Odpovědět

25.7.2019 9:03

Chybami se člověk učí, běžte se učit jinam!

Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 5 zpráv z 5.