дизайн таблицы базы данных для некоторых неизвестных данных - PullRequest
0 голосов
/ 21 февраля 2011

Итак, не имея опыта проектирования баз данных, мне было поручено разработать веб-приложение, в котором конечный пользователь будет вводить продукты и спецификации для своих продуктов.Обычно я думаю, что я просто создаю строки для каждого из типов спецификации, которые они будут вводить.Вместо этого у них есть множество продуктов, которые не разделяют одни и те же типы спецификаций, поэтому мой вопрос: каков наиболее эффективный и перспективный способ организации этих данных?Я склонялся к тому, чтобы поместить сериализованный объект в общую строку «данных», но можете ли вы выполнить полнотекстовый поиск по этим данным?Есть ли другие пути для изучения?

Ответы [ 4 ]

2 голосов
/ 21 февраля 2011

разделите продукты и спецификации на две таблицы, подобные этой:

products
id name

specifications
id name value product_id

получить все характеристики продукта, когда вы знаете идентификатор продукта:

SELECT  name,
        value
FROM    specifications
WHERE   product_id = ?;

добавить спецификацию к продукту, когда вы знаете идентификатор продукта, название спецификации и значение указанной спецификации:

INSERT INTO specifications(
    name,
    value,
    product_id
) VALUES(
    ?,
    ?,
    ?
);

поэтому, прежде чем вы сможете добавить спецификации к продукту, этот продукт должен существовать. Кроме того, вы не можете повторно использовать спецификации для нескольких продуктов. это потребует более сложного решения :) а именно ...

три таблицы на этот раз:

products
id name

specifications
id name value

products_specifications
product_id specification_id

получить все спецификации продукта, когда вы знаете идентификатор продукта:

SELECT  specifications.name,
        specifications.value
FROM    specifications
JOIN    products_specifications
ON      products_specifications.specification_id = specifications.id
WHERE   products_specifications.product_id = ?;

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

сначала найдите идентификатор спецификации:

SELECT  id
FROM    specifications
WHERE   name = ?
AND     value = ?;

если идентификатор не возвращается, это означает, что указанная спецификация не существует, поэтому ее необходимо создать:

INSERT INTO specifications(
    name,
    value
) VALUES(
    ?,
    ?
);

далее, либо используйте идентификатор из запроса select, либо получите последний идентификатор вставки, чтобы найти идентификатор вновь созданной спецификации. используйте этот идентификатор вместе с идентификатором продукта, который получает новую спецификацию, и свяжите их вместе:

INSERT INTO products_specifications(
    product_id,
    specification_id
) VALUES(
    ?,
    ?
);

однако, это означает, что вам нужно создать одну строку для каждой конкретной спецификации. например если у вас есть размер для обуви, для каждого известного размера обуви будет один ряд

specifications
id name value
1  size 7
2  size 7½
3  size 8

и так далее. Я думаю, этого должно быть достаточно.

0 голосов
/ 23 февраля 2011

Это довольно распространенная проблема - и для разных сценариев существуют разные решения.

Если различные типы продуктов и их атрибуты фиксированы и известны во время разработки, вы можете посмотреть описание в книге Крейга Лармана (http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062/ref=sr_1_1/002-2801511-2159202?ie=UTF8&s=books&qid=1194351090&sr=1-1) - есть раздел об объектно-реляционном отображении и о том, как обращаться с ним).наследование. Это сводится к тому, чтобы «поместить все возможные столбцы в одну таблицу», «создать одну таблицу для каждого подкласса» или «поместить все элементы базового класса в общую таблицу и поместить данные подкласса в их собственные таблицы».

Это, безусловно, самый естественный способ работы с реляционной базой данных - он позволяет создавать отчеты, использовать готовые инструменты для реляционного сопоставления объектов, если вам это нравится, и вы можете использовать стандартные концепциитакие как «не ноль», индексирование и т. д.

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

У меня естьвидно 3 общих подхода.

Первый описан davogotland. Я построил решение на аналогичных линиях дляинтернет-магазин;это прекрасно работало и позволило нам быть очень гибкими в отношении базы данных продуктов.Он работал очень хорошо, даже с полмиллиона продуктов.Основными недостатками было создание поисковых запросов - например, «найти все продукты с ценой ниже x в категории y, производителем которой является z».Также было сложно привлечь новых разработчиков - у них была довольно крутая кривая обучения.Это также заставило нас внедрить много реляционных концепций на уровень приложений.Например, было трудно создавать внешние ключи для других таблиц (например, «производитель») и применять их с использованием стандартных функций SQL.

Второй подход, который я видел, - тот, который вы упомянули - хранение переменных данных в каком-то сериализованном формате.Это боль при запросе, и она страдает теми же недостатками, что и реляционная модель.В целом, я бы хотел использовать сериализацию только для тех данных, которые вам не нужно запрашивать или рассуждать.

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

0 голосов
/ 22 февраля 2011

Я никогда не создавал базу данных продуктов, но я могу указать вам модель данных для этого.Это одна из более чем 200 моделей, доступных для ознакомления в базе данных ответов. Вот модель

Если вам не нравится эта модель, вы можете найти 15 различных моделей данных для баз данных, ориентированных на продукт.Нажмите «Модели данных», чтобы получить список, и прокрутите вниз до «Продукты».

Вы должны найти там несколько хороших дизайнерских идей.

0 голосов
/ 21 февраля 2011

Вы можете взглянуть на использование EAV модели .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...