Голема табела или неколку засебни табели (прашање за дизајн на база на податоци)
Ова е прашање за дизајн на база на податоци.
Сакам да изградам веб-апликација за фактура, фактурата може да има повеќе ставки и секој корисник може да има список со ставки од производот што може да ги зачува и да избере да ги додаде на ставка од фактурата.
Моите прашања се:
1. Дали треба да го чувам целиот попис на производи за сите корисници кои ја користат мојата апликација во една табела? Или имате посебна табела за попис на производи креирана за секој корисник? 2. Ова е дури можно?
1 маса е полесна, но ако една маса расте преголема, дали ќе имам проблем? (примарен клуч INT).
5 одговори
Една табела по корисник е лоша идеја. Чувајте го целиот инвентар во една табела, внесена на userid. Табелата треба да биде доволно масивна за ова да биде проблем за која било индустриска МСП (треба да почекате додека имате десетици милиони редови пред да поставите такви прашања).
Ако најчесто пристапувате до инвентарот од страна на корисникот, можете да ги забрзате ваквите пребарувања со тоа што корисникот ја прави првата колона на групираниот клуч, принудувајќи го пописот на корисникот да се собере на дискот. Сепак, повторно, дури и не размислувајте за овие проблеми сè додека не забележите вистинска деградација на перформансите.
Овие се генерирани производи од корисникот или вие ги контролирате?
Во секој случај, мислам дека ќе имате табела за производи и табела за корисници. Во зависност од изворот на производите (со други зборови, ако тие се исклучиво и веројатно поставени од корисникот или ако се достапни од кој било број на корисници), тогаш треба да имате табела што ги вознемирува корисниците на производите. Ако производите се навистина ексклузивни за одреден корисник, тогаш доволно е само зачувување на кориснички проект со регистрација на производот.
Не грижете се за големината на масата, барем не првично. SQL Server е моќна алатка за бази на податоци, само проверете дали имате добра нормализација на базата на податоци и правилно индексирање.
Како што расте табелата, конфигурацијата и распоредот на вашиот сервер ќе започне да има поголема важност, како и вашиот избор на индекси и како ги пишувате вашите прашања. Меѓутоа, ако не очекувате да имате многу милиони редови, не, нема да имате премногу редови за табелата да работи добро.
Општо правило е дека табелите треба да содржат податоци, но не и податоци. Ако започнете да ја гледате табелата, наведете за кои податоци станува збор, веројатно сте во категорија 2 и треба да направите резервна копија и да размислите за тоа што правите.
Опцијата 2 има проблеми. Thisо Целко се однесува на овој недостаток во дизајнот како поделба на масата; Податоците Крис се повикуваат на ова како кршење на принципот на ортогонален дизајн .
Ако секој корисник има посебен сет на производи што ги поседува или управува, една табела може да се подели подоцна. Како што сугерираат другите, не мора да се грижите за перформансите, освен ако не очекувате десетици милиони производи.
Јас би предложил да започнеме со еден оброк. Ако дизајнот на производот е идентичен за секој корисник, ова е многу едноставен и ефикасен дизајн.
Меѓутоа, ако производите поврзани со различни корисници бараат друга шема, може да завршите со многу тесна табела (многу празни/NULL полиња во секој запис, што ќе влијае на перформансите за секого).
Вообичаен пристап во овој поглед е табелата EAV (субјект-атрибут-вредност), која има три колони: проект на производ, име на атрибут и вредност на атрибутот. Ова е целосно динамично решение и е многу едноставно. Сепак, тоа го отежнува спроведувањето на декларативни ограничувања.
Најпосакуван пристап за динамична шема е да ги направам статичките/секогаш потребните полиња дел од постојаната шема/табела. Динамичкиот дел може да се креира како xml поле и да се ограничи со xml шема (или колекција). Интегритетот на податоците може да се спроведе на овој начин и ви треба само едно поле за дополнителни битови.