Дизайн схемы базы данных

Наиболее распространенный способ - хранить элементы заказа в другой таблице.

TBL_ORDER:
ID
TBL_CUSTOMER.ID

TBL_ORDER_ITEM:
ID
TBL_ORDER.ID
TBL_PRODUCTS.ID
Quantity
UniqueDetails

То же самое может относиться к контрольному следу вашего заказа. Это может быть новая таблица, например

TBL_ORDER_AUDIT:
ID
TBL_ORDER.ID
AuditDetails

Прежде всего, третья нормальная форма Google. В большинстве случаев ваши таблицы должны быть 3NF, но есть случаи, когда это не так из-за производительности или простоты использования, и только опыт может действительно научить вас этому.

То, что у вас не нормализовано. Для реализации связи "многие ко многим" необходима «таблица соединений».

TBL_ORDER:
ID
TBL_CUSTOMER.ID

TBL_ORDER_PRODUCT_JOIN:
ID
TBL_ORDER.ID
TBL_Product.ID
Количество

TBL_ORDER_AUDIT:
ID
TBL_ORDER.ID
Audit_Details

Взгляните на Agile Web Development with Rails, в нем есть отличный раздел об ActiveRecord (реализация одноименного шаблона проектирования в Rails) и он действительно хорошо объясняет эти типы отношений, даже если вы никогда не используете Rails. Вот также хорошее онлайн-руководство.

Основное условное имя столбца идентификатора в таблице Заказы (множественное число, потому что ORDER является ключевым словом в SQL) - «Номер заказа» с различным точным написанием (OrderNum, OrderNumber, Order_Num, OrderNo, ...).

Префикс TBL_ лишний; это вдвойне излишне, поскольку это не всегда означает таблицу, как, например, в имени столбца TBL_CUSTOMER.ID, используемом в таблице TBL_ORDER. Кроме того, вообще плохая идея - пробовать использовать "." в середине названия столбца; вам придется всегда рассматривать это имя как идентификатор с разделителями, заключая его либо в двойные кавычки (стандартный SQL и большинство СУБД), либо в квадратные скобки (MS SQL Server; не уверен в Sybase).

Джо Селко много говорит о таких вещах, как именование столбцов. Я не согласен со всем, что он говорит, но это легко найти. См. Также Фабиан Паскаль «Практические вопросы управления базами данных».

Другие ответы предполагали, что вам нужна таблица «Элементы заказа» - они правы; ты сделаешь. В ответах также говорилось о хранении количества там. Не забывайте, что вам нужно больше, чем просто количество. Например, вам понадобится цена, действующая на момент заказа. Во многих системах вам также может потребоваться иметь дело со скидками, налогами и другими деталями. А если это сложный элемент (например, самолет), в заказе может быть только один «элемент», но будет записано огромное количество второстепенных деталей.

Изучите моделирование отношений сущностей (ER) для анализа требований к базе данных.

Изучите проектирование реляционной базы данных и некоторое моделирование реляционных данных для общего логического проектирования таблиц. Нормализация данных - важная часть этой статьи, но далеко не все, что нужно изучить. Дизайн реляционной базы данных практически не зависит от СУБД в рамках основных продуктов СУБД.

Изучите физический дизайн базы данных. Изучите дизайн индекса как первый этап проектирования для повышения производительности. Дизайн некоторых индексов не зависит от СУБД, но физический дизайн становится все более зависимым от специальных функций вашей СУБД по мере того, как вы становитесь более подробными. Для этого может потребоваться книга, специально разработанная для СУБД, которую вы собираетесь использовать.

Вам не нужно делать все вышеперечисленное, прежде чем вы когда-либо спроектируете и создадите свою первую базу данных. Но то, чего вы не знаете, БУДЕТ вам больно Как и в случае с любым другим навыком, чем больше вы им занимаетесь, тем лучше вы становитесь. А изучение того, что уже знают другие, намного дешевле, чем изучение методом проб и ошибок.

Хотя я и не являюсь справочником по проектированию схем базы данных, я часто использую библиотеку схем по адресу DatabaseAnswers.org. Это хорошее место для прыжков, если вы хотите иметь что-то, что уже было обработано. Они не идеальны и, скорее всего, их нужно будет модифицировать в соответствии с вашими потребностями, но их там более 500.