Схема схемы базы данных для большого количества столбцов

Question

У меня есть вариант использования, где мне нужно моделировать справочные данные, например. различные вкусы мороженого. Скажем, у меня 50 ароматов мороженого: -

• 20 атрибутов, например. морозостойкость, сливовость будет распространяться по всем вкусам
• каждый аромат мороженого должен иметь 20-30 атрибутов, которые не будут использоваться другими ароматизаторами, например. : -
  • Клубничное мороженое может отслеживать терпкость, процент фруктов и т.д.
  • Шоколадное мороженое может отслеживать горечь, уровень какао и т.д.

Как бы смоделировать эти данные аккуратно в базе данных модели, чисто с точки зрения хранения/поиска?

варианты я могу думать: -

1. Одна таблица на вкус. Это потребует 50 таблиц, и каждая таблица будет иметь 20 столбцов, которые будут перекрываться друг с другом, и еще 20-30 атрибутов, которые будут уникальными для вкуса.
   • Плюсы: модели данных каждого аромата достаточно хорошо
   • Минусы: колонка перекрытия и большое количество таблиц необходимо
2. Один стол для всех вкусов. Для этого потребуется только одна таблица, но потребуется 1000+ столбцов, большинство из которых будут пустыми.
   • Плюсы: моделирующего данные мороженого в целом, достаточно хорошо
   • Минусы: большое количество столбцов и большое количество «впустую» пространство
3. Один стол ключ-значение для всех вкусов, с Идентификатор вкуса, имя атрибута и значение атрибута.
   • Плюсы: проще создавать и вставлять данные
   • Минусы: труднее извлечь, на самом деле не модель данных сама по себе, трудно сформировать ограничения для атрибутов, или для атрибутов, связанных с другими атрибутами

Answer 1

У меня будет одна таблица со всеми общими атрибутами, затем другая для не разделяемых атрибутов. Например:

CREATE TABLE ICE_CREAM_FLAVOR 
    (FLAVOR   VARCHAR2(100) PRIMARY KEY, 
    FREEZING_TEMP NUMBER, 
    CREAMINESS  NUMBER, 
    ETC    VARCHAR2(25), 
    BLAH   NUMBER); 

CREATE TABLE ICE_CREAM_FLAVOR_ATTRIBUTE 
    (ID_ICF_ATTRIBUTE NUMBER, -- should be populated by an insert trigger 
    FLAVOR   VARCHAR2(100) 
    NOT NULL 
    REFERENCES ICE_CREAM_FLAVOR(FLAVOR), 
    ATTRIBUTE_NAME VARCHAR2(25), 
    ATTRIBUTE_VALUE VARCHAR2(100)); 

Ваш пробег может отличаться.

Делитесь и наслаждайтесь.

Answer 2

Я хотел бы предложить, вы можете создать 3 разных таблицы.

1. Вкус мороженого: вы можете хранить все ароматы мороженого. Это будет таблица icecream_flavor_master. Скажем, если у вас есть 50 ароматов, чем 50 рядов, то создайте, например, Strawberry, Chocolate и т. Д.

2. Атрибуты мороженого: вы можете хранить все атрибуты мороженого. Это будет таблица icecream_attribute_master. Пусть говорят, что если у вас есть 50 атрибутов, чем 50 строк, создадут, например, терпкость, горечь, процент фруктов, уровень какао и т. Д.

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

Позвоните мне, чтобы узнать дополнительную информацию.

Answer 3

Никогда не храните значение не в том типе.

Независимо от дизайна вы выбрали, убедитесь, что значения сохраняются в их естественном формате. Используйте NUMBER, DATE, VARCHAR2, CLOB, XMLTYPE, CLOB (IS JSON), TIMESTAMP и т. Д. Попытка перерезать все в строке вызовет множество проблем. Вы теряете проверку, удобство, производительность и безопасность типов.

Например, здесь существует общая проблема безопасности. Представьте себе этот простой запрос, чтобы найти мороженое, которое более 25% плодов:

select * 
from ice_cream_flavor_attribute 
where attribute_name = 'Fruit Percentage' 
    and attribute_value > 25; 

Видите ли вы ошибку? Вы видите, как один и тот же запрос с одними и теми же данными может работать один день, а другой - с ORA-01722: invalid number?

Трудно написать запрос, который заставляет Oracle оценивать условия в определенном порядке. Повторное упорядочение предикатов не поможет (99,9% времени). Добавление встроенного представления не поможет (99,9% времени). Использование инструкции CASE будет работать, но не в 100% случаев. Использование подсказок будет работать, но сложно. Использование встроенного представления и ROWNUM является моим предпочтительным способом решения проблемы, но это выглядит странно и трудно понять.

---

Если вы должны использовать модель значения атрибута Entity (и если у вас есть более 1000 атрибутов может быть неизбежным), по крайней мере использовать правильные типы.

Не беспокойтесь о пространстве - в нулевом столбце используется не более 1 байт.

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

Answer 4

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

Если вы хотите сделать ER-моделирование, просмотрите «обобщение/специализацию» в Интернете. Некоторые веб-сайты назовут эту функцию «Расширенное моделирование ER» или EER.

Если вы хотите создать реляционные таблицы для реализации ER-дизайна, рассмотрите два шаблона: Наследование отдельных таблиц и Наследование классов.
https://stackoverflow.com/tags/single-table-inheritance/info

https://stackoverflow.com/tags/class-table-inheritance/info

Кроме того, обратите внимание на лечение Мартина Фаулера на эту тему в Интернете, или в одном из своих учебников.

Answer 5

Какие крупные производители делают для огромных данных в ECM (управление корпоративным контентом), где у вас довольно похожий сценарий (многие пользовательские классы с настраиваемыми атрибутами, некоторые из них могут быть одинаковыми, с разными типами атрибутов):

3. Одна таблица ключевых значений для всех вкусов, с идентификатором аромата, именем атрибута и значением атрибута.

Они используют одну таблицу значений ключа для каждого типа (строка, число, дата и т. Д.).

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

Выделенные таблицы имеют смысл для:

• Массивного использования (имеющих много строк)
• Bad гистограмм (например, флаги)

В противном случае индекс Oracle может быть обманут, и полный доступ таблицы самый быстрый доступ, что было бы очень плохо. Так что подумайте рано о производительности, имея огромное количество данных.