Rada při návrhu db tabulek

hechj

Re:Rada při návrhu db tabulek
« Odpověď #15 kdy: 21. 06. 2021, 20:24:28 »
Já vím, je to jako pro blbce, ale mně se to osvědčilo. Dělal jsem na db s 1000 tabulkami a všechny obsahovaly desítky sloupců pro všechny verze aplikace. Takovými id sloupci se to jen hemžilo. Navíc se to přepisovalo, takže dokonalý guláš. Když koukám do tabulky, kde jsou takové pleonasmy, vidím na první pohled, kam to vede. Tím bych to uťal, každý má nějaký styl, pán si jistě vybere


Re:Rada při návrhu db tabulek
« Odpověď #16 kdy: 21. 06. 2021, 23:51:35 »
Proč? Salary.id říká docela přesně, o co se jedná. Nesnáším pleonasmy.

Protože u tabulek v dotazech používáte aliasy a u cizích klíčů stejně musíte uvést jiné označení, než jen "id".
PostgreSQL (a myslím, že i další) zápis joinů ujednodušit, pokud se jména sloupců shodují (a prosté "id" se shoduje u více tabulek).

Takže místo
Kód: [Vybrat]
SELECT ... FROM sallary AS s INNER JOIN employee AS e ON s.employee_id = e.id
zapíšete pouze
Kód: [Vybrat]
SELECT ... FROM sallary AS s INNER JOIN employee AS e USING (employee_id)
Je to pak čitelnější, méně náchylné na chyby.
Má to pak zase jiné, menší nevýhody - ale určitě nejde říct, že používat prosté "id" je lepší.

Re:Rada při návrhu db tabulek
« Odpověď #17 kdy: 22. 06. 2021, 06:43:46 »
Proč? Salary.id říká docela přesně, o co se jedná. Nesnáším pleonasmy.

Protože u tabulek v dotazech používáte aliasy a u cizích klíčů stejně musíte uvést jiné označení, než jen "id".
PostgreSQL (a myslím, že i další) zápis joinů ujednodušit, pokud se jména sloupců shodují (a prosté "id" se shoduje u více tabulek).

Takže místo
Kód: [Vybrat]
SELECT ... FROM sallary AS s INNER JOIN employee AS e ON s.employee_id = e.id
zapíšete pouze
Kód: [Vybrat]
SELECT ... FROM sallary AS s INNER JOIN employee AS e USING (employee_id)
Je to pak čitelnější, méně náchylné na chyby.
Má to pak zase jiné, menší nevýhody - ale určitě nejde říct, že používat prosté "id" je lepší.

Já osobně nemám USING rád. Nedej bože NATURAL JOIN. Konvenci tabulka_sloupec používám pro cizí klíče, ale už ne pro primární - pak by nebylo poznat, co je primární klíč a co cizí klíč. Navíc, a to vychází od Joe Celka, v případě, že máte název tabulky zkopírovaný v názvu sloupce, tak si nemůžete pomoct aliasy. A pokud máte delší názvy tabulek, tak zákonitě musí být dotaz delší a asi hůře čitelný.

Pokud se s databází nepracuje ručně (schéma generuje CASE, dotazy ORM nebo query designer), tak je to asi jedno, ale při ruční editaci jsou rozumně dlouhé identifikátory základ.
« Poslední změna: 22. 06. 2021, 06:45:49 od Pavel Stěhule »

PanVP

  • *****
  • 958
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #18 kdy: 22. 06. 2021, 09:27:58 »

Předně, ač s vámi často nesouhlasím, vašeho názoru si velmi vážím.
Nicméně @Miroslav Šilhavý má v tom pravdu, USING umí být velmi užitečný.

Můžete to víc rozvést?
Tohle je myslím velmi zajímavé.
Osobně nemám rád některé nové funkcionality C#, ale to neznamená, že jsou špatné.
Je to vaše osobní preference, nebo jste se setkal se skutečnými problémy, které to způsobilo?

A dále, zmiňujete:
při ruční editaci jsou rozumně dlouhé identifikátory základ

Mohl byste to prosím ilustrovat na příkladu?
Děkuji, opravdu bych takové doporučení považoval za užitečné.

Re:Rada při návrhu db tabulek
« Odpověď #19 kdy: 22. 06. 2021, 09:52:30 »
...

Mně přijde USING poměrně šikovné, protože už zápisem vidím, jestli se spojovací podmínka (více) přirozená, nebo komplikovanější. Ale to je asi jen věc zvyku. Většina SQL se bez USING () obejde, takže to nepovažuji za mantru.

Identifikátory nemusejí být tabulka_id, ale zapsané i opačně: "id_tabulka. To docela eliminuje problém s dlouhými názvy (kdy se člověk dozví, že se jedná o identifikátor až na konci).

Jako výhodu také vidím práci s pohledy. Při definici pohledu se pak jednodušeji přebírají identifikátory do výběru.

Kód: [Vybrat]
CREATE VIEW ... AS
    SELECT
        ...
        , id_tabulka
    FROM
        tabulka INNER JOIN druha_tabulka USING (id_tabulka)

Při vytváření pohledu to pak získá možnost pohlídat, jestli je takový zápis jednoznačný. Pokud se jedná o INNER JOIN, tak to projde, pokud se jedná o OUTER JOIN, upozorní mě to a mnohdy předejde chybě. Pokud bych používal vždy plný zápis
Kód: [Vybrat]
SELECT tabulka.id AS tabulka_id připravím se o tuto výhodu a musím si dát dvojitý pozor, o jaký join se jedná a co je vlevo a co vpravo.

Proti tomu mně střídmost v pojmenování identifikátorů nepřijde tak důležitá, protože IDE stejně našeptávají a klíče naznačují.

Ale o tom se opravdu nehádám jako o jediné pravdě, všemi způsoby to jde, a jsou různá pro a proti.




Re:Rada při návrhu db tabulek
« Odpověď #20 kdy: 22. 06. 2021, 10:57:48 »
Mohl byste to prosím ilustrovat na příkladu?
Děkuji, opravdu bych takové doporučení považoval za užitečné.

Každá konvence vede k trochu jinému zápisu. Funkčně je to úplně stejné.
Kód: [Vybrat]
SELECT zam_prijmeni, adr_ulice || adr_cp FROM zamestnanci JOIN adresy USING (zam_id)nebo
Kód: [Vybrat]
SELECT z.prijmeni, a.ulice || a.cp FROM zamestnanci z JOIN adresy a ON z.id = a.zamestnanec_id
První zápis vás nutí dodržovat konvenci (což je dobrá vlastnost), ale musím si pamatovat navíc prefixy. Druhý zápis je expresivnější, a mám možnost volby aliasů (a je zdůrazněný rozdíl mezi primárním a cizím klíčem)

Re:Rada při návrhu db tabulek
« Odpověď #21 kdy: 22. 06. 2021, 11:06:24 »
Druhý zápis je expresivnější, a mám možnost volby aliasů (a je zdůrazněný rozdíl mezi primárním a cizím klíčem)

Aliasy můžete volit i u prvního zápisu, v tomto ohledu se to neliší.

Re:Rada při návrhu db tabulek
« Odpověď #22 kdy: 22. 06. 2021, 11:18:55 »
Když se tabulka jmenuje sallary, nazvěte klíč sallary_id. Když je tabulka company, nazvěte klíč company_id. Jinak se v tom ztratíte velice lehce. Ať se stejná hodnota v databázi jmenuje stejně ať je to primární nebo cizí klíč nebo cokoliv jiného. Berte to jako "must do"
My sme zvykli este foreign key nazyvat company_id1, aby bolo na prvy pohlad jasne, ze je to fk a k comu patri. Tiez to dost pomahalo.

PanVP

  • *****
  • 958
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #23 kdy: 22. 06. 2021, 11:22:50 »
Velmi zajímavá diskuze, takové problémy s MongoDB rozhodně neřeším každý den.

Děkuji!

Re:Rada při návrhu db tabulek
« Odpověď #24 kdy: 22. 06. 2021, 11:34:51 »
Druhý zápis je expresivnější, a mám možnost volby aliasů (a je zdůrazněný rozdíl mezi primárním a cizím klíčem)

Aliasy můžete volit i u prvního zápisu, v tomto ohledu se to neliší.

Můžete, ale tím se "zdvojuje" prefix, a co jsem viděl, tak pokud se používá tato konvence, tak byla snaha nepoužívat aliasy.

Podle mne výhody, a nevýhody budou podobné jako např. u použití maďarské notace. Je to hodně podobné.


Re:Rada při návrhu db tabulek
« Odpověď #25 kdy: 22. 06. 2021, 11:42:41 »
Můžete, ale tím se "zdvojuje" prefix, a co jsem viděl, tak pokud se používá tato konvence, tak byla snaha nepoužívat aliasy.

Tohle nějak nechápu - ale nečetl jsem nic na toto téma. Když mám v klíči jméno tabulky, tak mi přijde, že tím spíš můžu použít krátké aliasy a orientaci mi poskytne právě prefix v identifikátoru klíče. Zatímco krátké identifikátory se mi zdají v kombinaci s tabulkovými aliasy méně čitelné (a.id vs. a.account_id). Je pravdou, že při inner joinech lze pracovat úplně bez prefixu i bez aliasu, a nesníží to čitelnost.

Nemáš k tomu nějaký text? Možná by to mohlo být podnětné.

Re:Rada při návrhu db tabulek
« Odpověď #26 kdy: 22. 06. 2021, 11:52:54 »
Můžete, ale tím se "zdvojuje" prefix, a co jsem viděl, tak pokud se používá tato konvence, tak byla snaha nepoužívat aliasy.

Tohle nějak nechápu - ale nečetl jsem nic na toto téma. Když mám v klíči jméno tabulky, tak mi přijde, že tím spíš můžu použít krátké aliasy a orientaci mi poskytne právě prefix v identifikátoru klíče. Zatímco krátké identifikátory se mi zdají v kombinaci s tabulkovými aliasy méně čitelné (a.id vs. a.account_id). Je pravdou, že při inner joinech lze pracovat úplně bez prefixu i bez aliasu, a nesníží to čitelnost.

Nemáš k tomu nějaký text? Možná by to mohlo být podnětné.

Možná je to víc o estetice (a ta je subjektivní) a až potom k tomu hledáme technické argumenty. Podobné je to třeba s formátováním SQLka. Ten subjektivní pocit je důležitý pro mentální pohodu, ale zároveň to vylučuje větší shodu.

Mně vyhovuje a vycházím ze stylu Joe Celka Joe Celko's "SQL Programming Style"

https://www.sqlstyle.guide/


Re:Rada při návrhu db tabulek
« Odpověď #27 kdy: 22. 06. 2021, 12:00:42 »
Možná je to víc o estetice (a ta je subjektivní) a až potom k tomu hledáme technické argumenty.

Já, doufám, ani ne. Považuji všechny ty styly (co jsme si tu řekli) za technicky rovnocenné. Technicky mi vadí snad jen, pokud se v jedné databázi najde mix stylů - s tím už se pak opravdu špatně pracuje snad každému.

Díky za odkaz.

SB

  • ****
  • 306
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #28 kdy: 22. 06. 2021, 12:33:39 »
Tohle relační eskamotérství mi vždy připomene, jak nám vyučující vykládal vtip, jaký je rozdíl, když se kupuje vánoční stromeček v objektovém, nebo relačním obchodu.

PanVP

  • *****
  • 958
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #29 kdy: 22. 06. 2021, 12:48:43 »
vtip

Ten neznám, sem s ním  ;D

https://www.sqlstyle.guide/
To jsem neznal, moc pěkné mít to takhle pohromadě!!!
« Poslední změna: 22. 06. 2021, 12:52:09 od PanVP »