Модель базы данных и производительность

Question

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

Прежде всего, у меня есть стол для моих продуктов. Он содержит только общие данные, такие как id и articlenr, для всех атрибутов продукта (таких как имя, цена и т. Д.). Я создал отдельные таблицы для каждого типа, поэтому у меня есть следующие таблицы:

product_att_varchar
product_att_decimal
product_att_int
product_att_select
product_att_text
product_att_date

эти таблицы связаны реляционной таблицей procuct_att_relational

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

У кого-нибудь есть решение для этого ???

Спасибо

Answer 1

Эта модель называется EAV (entity-attribute-value) и имеет свои недостатки и преимущества.

Преимущества в том, что он очень гибкий и легко расширяется. Это может быть полезно, если у вас очень большое количество очень разреженных атрибутов, атрибуты не могут быть предсказаны во время разработки (скажем, предоставлены пользователем) или атрибуты, которые используются редко.

Недостатками являются производительность и невозможность индексировать несколько атрибутов одновременно. Однако если ваша система баз данных допускает индексированные представления (например, SQL Server) или кластеризованное хранилище из нескольких таблиц (например, Oracle), то с помощью этих методов производительность может быть улучшена.

Однако сохранение всех атрибутов в одной записи будет происходить быстрее.

Answer 2

Я не вижу веской причины убирать эти атрибуты из таблицы продуктов.Было бы одно, если бы вы сделали это, потому что у вас были некоторые данные, которые наводили на мысль о проблеме, но, похоже, вы думали, что «это будет лучше».Почему вы сделали это так сразу?

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

Answer 3

Люди продолжают возвращаться к этой модели, потому что они думают, что она «гибкая».Ну, я полагаю, что гибкость имеет огромную цену: каждое обновление и каждый запрос медленные и сложные.Quassnoi упоминает, что если атрибуты редки, то есть большинство экземпляров сущности имеют только небольшой процент возможных атрибутов, это может сэкономить место.Это правда, но с другой стороны, если это не редкость, это занимает значительно больше места, потому что теперь вам нужно хранить имя атрибута или код для каждого атрибута в дополнение к значению, плюс вам нужно повторить какой-то видключ для идентификации экземпляра логической сущности для каждого атрибута.

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

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