Veľká tabuľka alebo niekoľko samostatných tabuliek (otázka návrhu databázy)
Toto je otázka návrhu databázy.
Chcem vytvoriť webovú aplikáciu pre faktúry, faktúra môže obsahovať viac položiek a každý používateľ môže mať zoznam položiek produktu, ktoré môže ukladať, a zvoliť, či bude k položke faktúry pridaný.
Moje otázky sú:
1. Mám uložiť celý inventár produktov pre všetkých používateľov, ktorí používajú moju aplikáciu, do jednej tabuľky? Alebo máte pre každého používateľa vytvorenú samostatnú tabuľku inventára produktov? 2. To je dokonca možné?
1 stôl je ľahší, ale ak jeden stôl príliš dorastie, budem mať problém? (primárny kľúč INT).
5 odpovedí
Jedna tabuľka na používateľa je zlý nápad. Uchovávajte všetok svoj inventár v jednej tabuľke napísanej na userid. Tabuľka by mala byť dostatočne masívna, aby to mohlo robiť problém akýmkoľvek priemyselným malým a stredným podnikom (ešte predtým, ako takéto otázky položíte, počkajte, kým nebudete mať desiatky miliónov riadkov).
Ak k inventáru pristupujete najčastejšie používateľom, môžete tieto dotazy urýchliť tak, že sa userid stane prvým stĺpcom zoskupeného kľúča a vynútite tak, aby sa inventár používateľov zhromaždil na disku. Opäť však na tieto problémy ani nepomyslite, kým nezistíte skutočné zníženie výkonu.
Jedná sa o produkty generované používateľmi alebo ich ovládate?
V každom prípade si myslím, že budete mať tabuľku s produktmi a tabuľku pre používateľov. V závislosti od zdroja produktov (inými slovami, ak sú výlučne a pravdepodobne nahrané používateľom alebo ak sú prístupné ľubovoľnému počtu používateľov), mali by ste mať tabuľku, ktorá obťažuje používateľov týchto produktov. Pokiaľ sú produkty skutočne exkluzívne pre konkrétneho používateľa, potom by stačilo iba uložiť ID užívateľa s registráciou produktu.
Nerobte si starosti s veľkosťou stola, aspoň spočiatku nie. SQL Server je výkonný databázový nástroj, len sa uistite, že máte dobrú normalizáciu databázy a správne indexovanie.
Ako bude tabuľka pribúdať, na konfigurácii a rozložení vášho servera začne záležať viac, rovnako ako váš výber indexov a spôsob písania vašich dotazov. Ak však neočakávate, že budete mať veľa miliónov riadkov, nie, nebudete mať príliš veľa riadkov na to, aby tabuľka fungovala dobre.
Všeobecným pravidlom je, že tabuľky by mali obsahovať údaje, ale nie údaje. Ak začnete vidieť tabuľku, uveďte, o aké údaje sa jednáte, pravdepodobne ste v kategórii 2 a musíte si urobiť zálohu a porozmýšľať, čo robíte.
Možnosť 2 má problémy. Joe Celko označuje túto chybu dizajnu ako rozdelenie stola; Údaje Chris to označujú za porušenie princípu ortogonálneho dizajnu .
Ak má každý používateľ samostatnú sadu produktov, ktoré vlastní alebo spravuje, je možné neskôr rozdeliť jednu tabuľku. Ako už iní navrhli, s výkonom sa nemusíte báť, pokiaľ neočakávate desiatky miliónov produktov.
Navrhoval by som začať s jedným jedlom. Ak je usporiadanie produktu rovnaké pre každého používateľa, jedná sa o veľmi jednoduchý a efektívny dizajn.
Ak však produkty súvisiace s rôznymi používateľmi vyžadujú inú schému, môžete skončiť s veľmi úzkou tabuľkou (veľa prázdnych polí/NULL polí v každom zázname, čo ovplyvní výkon všetkých).
Spoločným prístupom v tomto ohľade je tabuľka EAV (Entity-Attribute-Value), ktorá má tri stĺpce: id produktu, názov atribútu a hodnota atribútu. Jedná sa o úplne dynamické riešenie a je veľmi jednoduché. Sťažuje však vykonávanie deklaratórnych obmedzení.
Môj preferovaný prístup pre dynamickú schému je, aby sa statické/vždy potrebné polia stali súčasťou permanentnej schémy/tabuľky. Dynamická časť môže byť vytvorená ako pole xml a ohraničená schémou xml (alebo kolekciou). Integritu údajov je možné implementovať týmto spôsobom a pre ďalšie bity potrebujete jediné pole.