Голяма таблица или няколко отделни таблици (въпрос за проектиране на база данни)
Това е въпрос за дизайн на база данни.
Искам да изградя уеб приложение за фактура, фактурата може да има множество елементи и всеки потребител може да има списък с продуктови елементи, които може да съхранява и да избере да добави към елемент на фактура.
Въпросите ми са:
1. Трябва ли да съхранявам целия списък с продукти за всички потребители, които използват приложението ми, в една таблица? Или имате отделна таблица с инвентаризация на продукти, създадена за всеки потребител? 2. Това дори е възможно?
1 таблица е по-лесна, но ако една маса стане твърде голяма, ще имам ли проблем? (първичен ключ INT).
5 отговора
Една таблица на потребител е лоша идея. Съхранявайте целия си инвентар в една таблица, написана на идентификатор на потребителя. Таблицата трябва да е достатъчно масивна, за да може това да е проблем за всяка индустриална МСП (трябва да изчакате, докато имате десетки милиони редове, преди дори да зададете такива въпроси).
Ако достъпвате инвентара най-често от потребителя, можете да ускорите такива заявки, като направите идентификатора на потребителя първата колона на групиран ключ, принуждавайки инвентара на потребителя да се събира заедно на диска. Отново обаче, дори не мислете за тези проблеми, докато не забележите реално влошаване на производителността.
Това са генерирани от потребителя продукти или вие ги контролирате?
Във всеки случай мисля, че ще имате таблица за продукти и таблица за потребители. В зависимост от източника на продуктите (с други думи, ако те са изключително и вероятно качени от потребителя или ако са достъпни от произволен брой потребители), трябва да имате таблица, която тормози потребителите към продуктите. Ако продуктите наистина са изключително за конкретен потребител, тогава само съхраняването на потребителски идентификатор с регистрацията на продукта би било достатъчно.
Не се притеснявайте от размера на масата, поне не първоначално. SQL Server е мощен инструмент за бази данни, просто се уверете, че имате добра нормализация на базата данни и правилно индексиране.
С нарастването на таблицата конфигурацията и оформлението на вашия сървър ще започнат да имат по-голямо значение, както и изборът ви на индекси и начина, по който пишете заявките си. Ако обаче не очаквате да имате много милиони редове, не, няма да имате твърде много редове, за да може таблицата да работи добре.
Общо правило е, че таблиците трябва да съдържат данни, но не и данни. Ако започнете да виждате таблицата, посочете за какви данни става въпрос, вероятно сте в категория 2 и трябва да направите резервно копие и да помислите какво правите.
Вариант 2 има проблеми. Джо Селко се позовава на този дизайнерски недостатък като разделяне на масата; Данните, които Крис посочва като нарушаващи принципа на ортогоналния дизайн .
Ако всеки потребител има отделен набор от продукти, които притежава или управлява, една таблица може да бъде разделена по-късно. Както други предполагат, не е нужно да се притеснявате за производителността, освен ако не очаквате десетки милиони продукти.
Бих предложил да започнете с едно хранене. Ако дизайнът на продукта е идентичен за всеки потребител, това е много прост и ефективен дизайн.
Ако обаче продуктите, свързани с различни потребители, изискват различна схема, може да се окажете с много тясна таблица (много празни/NULL полета във всеки запис, което ще повлияе на производителността на всички).
Често срещан подход към това е таблицата EAV (Entity-Attribute-Value), която има три колони: идентификатор на продукта, име на атрибут и стойност на атрибута. Това е напълно динамично решение и е много просто. Това обаче затруднява прилагането на декларативни ограничения.
Моят предпочитан подход за динамична схема е да направя статичните/винаги необходими полета част от постоянната схема/таблица. Динамичната част може да бъде създадена като xml поле и ограничена от xml схема (или колекция). Целостта на данните може да бъде реализирана по този начин и ви е необходимо само едно поле за допълнителни битове.