Велика таблиця або кілька окремих таблиць (питання проектування бази даних)
Це питання проектування бази даних.
Я хочу створити веб-додаток для рахунків-фактур, рахунок-фактура може мати декілька позицій, і кожен користувач може мати список товарів, які він може зберігати та вибрати, щоб додати до елемента рахунку-фактури.
Мої запитання:
1. Чи слід зберігати весь асортимент товарів для всіх користувачів, які використовують мій додаток, в одній таблиці? Або у вас для кожного користувача створена окрема таблиця товарних запасів? 2. Це навіть можливо?
1 таблиця простіше, але якщо одна таблиця стане занадто великою, чи будуть у мене проблеми? (первинний ключ INT).
5 відповідей
Одна таблиця на користувача - погана ідея. Весь інвентар зберігайте в одній таблиці, набраній за ідентифікатором користувача. Стіл повинен бути достатньо масивним, щоб це стало проблемою для будь-якого промислового малого та середнього бізнесу (вам слід почекати, поки у вас з'являться десятки мільйонів рядків, перш ніж навіть задавати такі запитання).
Якщо користувач найчастіше отримує доступ до інвентаризації, ви можете пришвидшити такі запити, зробивши ідентифікатор користувача першим стовпцем згрупованого ключа, змусивши інвентар користувача збиратись разом на диску. Однак знову ж таки, навіть не думайте про ці проблеми, поки не помітите реального погіршення продуктивності.
Це створені користувачем продукти або ви керуєте ними?
У будь-якому випадку, я думаю, у вас буде таблиця для продуктів та таблиця для користувачів. Залежно від джерела продуктів (іншими словами, якщо вони виключно і, ймовірно, завантажені користувачем або якщо вони доступні будь-якій кількості користувачів), ви повинні мати таблицю, яка переслідує користувачів до продуктів. Якщо продукти дійсно є ексклюзивними для конкретного користувача, то досить буде просто зберігати ідентифікатор користувача з реєстрацією товару.
Не турбуйтеся про розмір столу, принаймні спочатку. SQL Server є потужним інструментом баз даних, просто переконайтеся, що у вас є нормальна база даних і нормальна індексація.
У міру зростання таблиці конфігурація та макет вашого сервера почнуть мати більше значення, як і вибір індексів та спосіб написання запитів. Однак, якщо ви не очікуєте мати багато мільйонів рядків, ні, у вас не буде занадто багато рядків, щоб таблиця працювала добре.
Загальним правилом є те, що таблиці повинні містити дані, але не дані. Якщо ви починаєте бачити таблицю, вкажіть, про які дані ви йдете, ви, мабуть, перебуваєте в категорії 2, і вам потрібно зробити резервну копію та подумати про те, що ви робите.
Варіант 2 має проблеми. Джо Селко називає цей недолік дизайну розбиттям столу; Дані Кріс називає це порушенням принципу ортогонального дизайну .
Якщо кожен користувач має окремий набір продуктів, якими він володіє або керує ними, пізніше можна розділити одну таблицю. Як припускали інші, вам не доведеться турбуватися про продуктивність, якщо ви не очікуєте десятків мільйонів продуктів.
Я б запропонував почати з одного прийому їжі. Якщо дизайн продукту ідентичний для кожного користувача, це дуже простий та ефективний дизайн.
Однак, якщо для продуктів, що стосуються різних користувачів, потрібна інша схема, у вас може вийти дуже вузька таблиця (безліч порожніх/NULL полів у кожному записі, що впливатиме на продуктивність кожного).
Загальним підходом у цьому відношенні є таблиця EAV (Entity-Attribute-Value), яка має три стовпці: ідентифікатор товару, ім'я атрибута та значення атрибута. Це абсолютно динамічне рішення і дуже просте. Однак це ускладнює впровадження декларативних обмежень.
Мій кращий підхід для динамічної схеми - зробити статичні/завжди необхідні поля частиною постійної схеми/таблиці. Динамічну частину можна створити як поле xml і обмежити xml-схемою (або колекцією). Цілісність даних може бути реалізована таким чином, і вам потрібно лише одне поле для додаткових бітів.