Sklad návrhů DB struktur v SQL

[prosprry]

Zdravím,
Existuje někde sklad pro návrháře databází?

• Ve kterém by se dali nalézt různé návrhy DB struktur.
• Každý má možnost vkládat projekty a verzovat.
• Nějaké pořádné zamřené fórum??

Potom nějaké vysvětlení 4 NF a 5NF které se dá pochopit, Hlavně JOIN což je základ nějak zatím nechápu, nemám k němu použití

Díky všem

[Reklama]

[javaman (ten nejlepší)]

Jako myslíš třeba někde ve sklepě a s učebnicemi?

[Kit]

Dokud nechápeš JOIN, můžeš v klidu zatím odložit 4NF i 5NF. Obejdeš se i bez nich, ale bez JOINu nikoli.

[Kit]

Návrhářů databází je docela dost, ale každý z nich má obvykle výstup pro některou konkrétní databázi. Je to z toho důvodu, že každá databáze je trochu jinak implementována. Na githubu se obvykle verzuje přími SQL, který se pro kooperaci moc nehodí. Lepší by byl určitě nějaky XML, JSON či YAML, který by se teprve ve finále serializoval do SQL.

[Filip Jirsák]

Pokud jste myslel, že GitHub je pro programátory, a zda existuje něco takového pro databázové architekty, pak:
* návrhy databáze se obvykle uchovávají spolu s celým projektem, stejně jako zdrojového kódy, návrhy vzhledu, obrázky apod. Systémy na správu verzí nejsou zaměřené výhradně na zdrojový kód programu, i když ten mívá největší podíl na obsahu. Takže vytvářet projekty a verzovat můžete v GitHubu úplně stejně, jako programátoři. Jde akorát o to, v jakém formátu tam ten návrh budete ukládat. Pokud to budou SQL příkazy, je to bez problémů, na práci s textovými soubory je Git stavěn. Pokud to budou soubory nějakého grafického návrháře databází, k tomu se Git bude chovat jako k BLOBu - ty soubory vám to uloží, ale nebudete moci porovnávat rozdíly atd. Ale to vychází z toho, že Git tomu formátu nerozumí a patrně jedinná aplikace, která mu rozumí, je příslušný grafický návrhář. Takže pokud chcete porovnávat verze nebo přenášet změny, pátrejte po tom, zda to umí ten grafický návrhář.
* Z předchozího bodu plyne i to, kde se dají nalézt návrhy databázových struktur - hledejte je přímo u projektů. Pokud nějaký projekt používá databázi, najdete návrh databázové struktury nejspíš v jeho zdrojácích - třeba na tom GitHubu.

Fóra zaměřená na databáze asi existují, případně mají sekce zaměřené na databáze obecná fóra (třeba Stack Overflow). Pokud ale nechápete, co je join, je na nějaké fórum moc brzo, nikdo vás nebude učit úplné základy. V takovém případě doporučuju spíš nějakou učebnici SQL pro začátečníky.

Třeba tohle diskusní fórum. Jednotlivé příspěvky jsou asi uložené v databázové tabulce. V jiné tabulce jsou informace o registrovaných uživatelích - a u každého příspěvku registrovaného uživatele je odkaz do tabulky uživatelů.  V další tabulce bude seznam témat - a od příspěvku opět vede odkaz do tabulky témat. Takže když se má vypsat stránka s příspěvky k danému tématu, musí se přes join spojit tři tabulky - tabulka s tématy (kde se vyhledá to jedno téma), tabulka s příspěvky (kde se vyhledají všechny, které patří k danému tématu) a tabulka s uživateli (odkud se ke každému příspěvku načte jméno uživatele, odkaz na jeho profil a případně další informace). Ale jak už jsem psal, tohle bude chtít nějakou učebnici základů.

[Reklama]

[anonym069]

Hlavně JOIN což je základ nějak zatím nechápu, nemám k němu použití

JOIN je klauzule pro spojení záznamů z více tabulek přes společné hodnoty "spojovacích" sloupečků.

Pokud znáte SQL, jistě znáte alespoň tento zápis (píši to spatra, omluvte případné chyby):

SELECT customer.customer_id, customer.name, order.order_time, order.total_price
FROM customer, order
WHERE customer.customer_id = order.customer_id
  AND order.total_price > 1000
  AND order.order_date >= CURRENT_DATE - 30


Toto lze přepsat s využitím JOINu:

SELECT customer.customer_id, customer.name, order.order_time, order.total_price
FROM customer
JOIN order
  ON customer.customer_id = order.customer_id
WHERE order.total_price > 1000
  AND order.order_date >= CURRENT_DATE - 30


S JOINem je to jednak mnohem přehlednější a čitelnější, jelikož podmínky pro spojování tabulek pak budou v JOIN částech a ostatní obecné podmínky (často nějaké externí parametry) zůstanou ve WHERE části. Je to znát obzvláště v případě, že spojujete více (třeba desítky) tabulek... pak má každá spojovaná tabulka svou JOIN část a v ní podmínky související jen s touto tabulkou.

A dále pak navíc jednoduchou změnou můžete snadno změnit typ spojení, třeba LEFT JOIN pro "nepovinné" spojení tabulky (LEFT = záznamy v tabulce vlevo jsou povinné, v tabulce vpravo, tedy připojované, jsou nepovinné), CROSS JOIN pro všechny možné kombinace přes všechny řádky (bez podmínky) apod.

Třeba ve výše uvedeném příkladu získáte všechna jména zákazníků, časů jejich objednávek a celkových cen objednávek za posledních 30 dní, kde celková cena objednávky byla vyšší než 1000. Zákazníci bez objednávky (splňující dané podmínky) by vůbec vypsáni nebyli. Změnou JOIN na LEFT JOIN pak získáte seznam úplně všech zákazníků... a u těch, jež žádnou objednávku (splňující podmínky) nemají, bude prostě ve sloupečcích z tabulky order prázdná hodnota.

[Ondrej Nemecek]

Někde jsem zahlédl něco jako kanonické příklady na databázovou strukturu, tj. příklad schématu, na který se pak odkazovala dokumentace a výuka. Jako myšlenka mi to přijde dobré. Tyhle příklady by mohly být nezávislé na konkrétním databázovém serveru, případně by právě šly ukázat různé odlišnosti. Bohužel si nepamatuju, kde jsem to viděl - asi to bylo u dokumentace k nějaké databázi (Mysql? Postgres? Oracle?)

Z schémat z githubu bych se neučil dříve, než budu bezpečně znát základy, jinak se snadno naučím nesmysly. Zaměřil bych se spíš na literaturu - ať už online nebo knižní. K sql databázím je jí tuny a pokud si člověk dobře vybere, je tam určitá záruka, že tam bude vše vysvětlené a navržené v základu správně a bez zatížení nějakými specifiky. Což se o příkladech z praxe nedá vždy říct.

[.]

Těžko najdeš něco lepšího než toto:

https://lagunita.stanford.edu/courses/DB/2014/SelfPaced/about