Разработка схемы базы данных

Question

Я довольно новичок в проектировании баз данных, у меня есть несколько вопросов о передовых практиках, и я действительно хотел бы учиться. Я разрабатываю схему базы данных, у меня есть четкое представление о требованиях, и теперь вопрос состоит в том, чтобы сделать ее черно-белой.

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

TBL_PRODUCTS:
ID
Описание
Подробнее

TBL_CUSTOMER:
ID
Имя
Адрес

TBL_ORDER:
ID
TBL_CUSTOMER.ID
prod1
prod2
prod3
и т.д.

Каждый «заказ» имеет только одного покупателя, но может иметь любое количество «продуктов».

Проблема в том, что в моем случае продукты для данного заказа могут быть любой суммы (сотни для одного заказа), кроме того, каждому продукту для заказа нужно больше, чем просто «количество», но они могут иметь значения которые охватывают страницы текста для конкретного продукта для конкретного заказа. У меня вопрос, как я могу хранить эту информацию?

Предполагая, что я не могу сохранить массив переменной длины в качестве значения одного поля, другой вариант - иметь строку, которая каким-либо образом разделена и разделена по коду в приложении. В заказе может быть указано, например, 100 товаров, каждый из которых имеет либо маленькое целое число, либо 5000 символов, либо свободный текст (или что-то среднее), уникальное только для этого заказа.

Кроме того, у каждого заказа должен быть свой собственный контрольный журнал, так как с ним может случиться много вещей в течение его срока службы. Контрольный журнал будет содержать обычную информацию - пользователя, время / дату, действие и может быть любой длины. Буду ли я хранить контрольный журнал для определенного заказа в его собственной таблице (поскольку они могут стать довольно длинными), созданной при создании заказа?

Есть ли места, где я мог бы больше узнать о методах проектирования баз данных?

Answer 1

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

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

Answer 2

Прежде всего, Google Third Normal Form. В большинстве случаев ваши таблицы должны быть 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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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