Návrh databáze...

Dělám na jednom projektu a potřeboval bych poradit s návrhem databáze. V rámci zachování výrobního tajemství (nápadu), uvedu obecný příklad: 2 tabulky - Uživatelé a Záznamy, webová aplikace by měla umožnit uživatelům hlasovat pro jednotlivé záznamy a u každého vypisovat seznam uživatelů, kteří pro něj hlasovali. Podobně jako zde, viz. seznam uživatelů, kteří "Linkovali". Jak navrhnout databázi tak, aby šli konkrétní uživatelé od každého Záznamu mazat a zase přidávat. Nějaké elegantní a rychlé řešení? Díky.

btw.: nejedná se o další linkovací portál ani nic podobného, prosím zdržte se OT

pridas jeste tabulku hlasovani, jenom s polozkama
(id)
uzivatel_id
zaznam_id

chápu to správně ?

Původně odeslal Pacek

Dělám na jednom projektu a potřeboval bych poradit s návrhem databáze. V rámci zachování výrobního tajemství (nápadu), uvedu obecný příklad: 2 tabulky - Uživatelé a Záznamy, webová aplikace by měla umožnit uživatelům hlasovat pro jednotlivé záznamy a u každého vypisovat seznam uživatelů, kteří pro něj hlasovali. Podobně jako zde, viz. seznam uživatelů, kteří "Linkovali". Jak navrhnout databázi tak, aby šli konkrétní uživatelé od každého Záznamu mazat a zase přidávat. Nějaké elegantní a rychlé řešení? Díky.

btw.: nejedná se o další linkovací portál ani nic podobného, prosím zdržte se OT

Já osobně bych ty uživatele všechny přidával do nějakého sloupce, třeba hlasy. Select bude rychlý - výpis uživatelů bude vlastně rozdělení řetězce nějakým znakem (například mezerou). Obsah řádku ve sloupci hlasy tedy bude vypadat třeba "zdenek jirka pavel".

Tabulka Záznamy pak bude mít dva sloupce - událost (záznam) a hlasy, při selectu vybereš obě a nic dalšího nepotřebuješ dělat - jednoduché a rychlé.

No a přidávat a zamaz uživatele půjde jednoduše - jde o práci s jednoduchým řetězcem - přidání uživatele - zápis na konec řetězce, smazání uživatele - smazání pořetězce uživatele, přičemž jeho jméno obklopují mezery...

hh, jo takhle to dělají začátečníci, kteří nezvládají složitější sql dotazy. Vtipné pak bude když při výpisu co všechno uživatel linkoval bude databáze fultextem prohledávat všechny záznamy a nedejbože bys chtěl umožnit uživatelům měnit přezdívku...a na indexy můžeš rovnou zapomenout.

Původně odeslal toshi

hh, jo takhle to dělají začátečníci, kteří nezvládají složitější sql dotazy. Vtipné pak bude když při výpisu co všechno uživatel linkoval bude databáze fultextem prohledávat všechny záznamy a nedejbože bys chtěl umožnit uživatelům měnit přezdívku...a na indexy můžeš rovnou zapomenout.

Mezerou by asi odděloval jejich ID. Ono to není až tak špatné řešení, pokud by to byl spíš kešovací řádek hodnot, protože by počet čtení vysoce převažoval počet zápisů

Prosím vás zapomeňte na ta řešení se sloupcem hlasování a nějakejma mezerama :rolleyes: Jediné správné řešení je další tabulka jak psal toshi

Toshi správně, ostatním doporučuji nastudovat pojem "první normální forma".

Díky za názory, využiju toshiho variantu.

A v případě, že bude poměr čtení zápis 1000:1? Opravdu je efektivnější při každém čtení složit z tabulky řádek? Pokud by se tento řádek sestavoval nějak inteligentně a fungoval pouze jako cache, tak by to asi nebylo úplně marné

Cachování řeš na jiné úrovni než ve struktuře DB.

Původně odeslal Souki

A v případě, že bude poměr čtení zápis 1000:1? Opravdu je efektivnější při každém čtení složit z tabulky řádek? Pokud by se tento řádek sestavoval nějak inteligentně a fungoval pouze jako cache, tak by to asi nebylo úplně marné

Na čtení a hledání v textu při velkém množství záznamů rovnou zapomeň. Toshiho řešení je jediná správná volba. I kdyby byl poměr 1000000:1 tak bude propojení tabulek přes 1:N rychlejší než procházení textu a to v několika řádech. Stačí správné rozložení indexů. Doporučuju nastudovat základy relačních databází.