Пары значения ключа в реляционной базе данных

Вашим примером не является очень хороший пример использования пар значения ключа. Лучшим примером было бы использование чего-то как таблица Fee таблица Customer и таблица Customer_Fee в приложении биллинга. Таблица Fee состояла бы из полей как: fee_id, fee_name, fee_description таблица Customer_Fee состоял бы из полей как: customer_id, fee_id, fee_value

Если Вы идете путем таблицы KVP, и я должен сказать, что мне не нравится та техника вообще самому, поскольку действительно трудно запросить, то необходимо рассмотреть кластеризацию значений для единственного идентификатора объекта вместе с помощью соответствующей техники для любой платформы, Вы идете.

RDBMS имеет тенденцию рассеять строки вокруг для предотвращения конкуренции блока на вставках и если Вы имеете 8, бродит для получения Вас, мог бы легко получить доступ к 8 блокам таблицы читать их. На Oracle Вы преуспели бы для рассмотрения кластера хеша для хранения их, которые значительно улучшат производительность относительно доступа к значениям для данного идентификатора объекта.

Если ключи являются динамичными, или существуют загрузки их, то используют таблицу отображения, которую Вы имеете как свой первый пример. Кроме того, это - самое общее решение, оно масштабируется лучше всего в будущем, поскольку Вы добавляете больше ключей, легко кодировать SQL для вывода данных, и база данных будет в состоянии оптимизировать запрос лучше, чем Вы вообразили бы (т.е. я не приложу усилия к преждевременной оптимизации этого случая, если это, как не доказывали, было узким местом в тестировании позже, в этом случае Вы могли рассмотреть следующие две опции ниже).

, Если ключи являются известным набором, и нет многих из них (< 10, возможно, < 5), тогда я не вижу проблемы в наличии их как столбцы значений на объекте.

, Если существует среднее количество известных починенных ключей (10 - 30) тогда, возможно, имеют другую таблицу для содержания item_details.

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

Я думаю, что Вы делаете правильную вещь, пока ключи/значения для данного типа объекта часто изменяются.
, Если они довольно статичны, тогда просто делая таблицу объекта шире, имеет больше смысла.

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

я могу записать больше деталей того, что мы делаем при необходимости.

Вторая таблица является плохо денормализованной. Я придерживался бы первого подхода.

Нарушение правил нормализации прекрасно, пока бизнес-требование может все еще быть выполнено. Наличие key_1, value_1, key_2, value_2, ... key_n, value_n может быть в порядке, вплоть до точки, в которой Вы нуждаетесь key_n+1, value_n+1.

Моим решением была таблица данных для общих атрибутов и XML для уникальных атрибутов. Это означает, что я использую обоих. Если все (или большинство вещей) имеет размер, то размер является столбцом в таблице. Если только возражают, что A имеют атрибут Z, то Z хранится как XML ответ подобного Peter Marshall, уже данный.

Первый метод намного более гибок по стоимости, которую Вы упоминаете.

И второй подход никогда не жизнеспособно, когда Вы показали. Вместо этого Вы сделали бы (согласно Вашему первому примеру)

create table item_config (item_id int, colour varchar, size varchar, fabric varchar)

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

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

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

Или он так, чтобы каждый объект мог только иметь конечное число ключей, но ключи могли быть чем-то от большого набора?

Вы могли также рассмотреть использование Объектного Реляционного Картопостроителя для создания запросов легче.

первый метод довольно в порядке. можно создать UDF, который извлекает желаемые данные, и просто назовите это.

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

SELECT itemkey,itemvalue FROM key_value_pairs WHERE itemid='123';

или если Вы просто хотите один конкретный ключ для того объекта:

SELECT itemvalue FROM key_value_pairs WHERE itemid='123' AND itemkey='Fabric';

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

На основе опыта я нашел, что определенные ключи будут более широко использоваться или запрашиваться чаще. Мы обычно тогда немного денормализовывали дизайн для включения определенного поля назад в основную таблицу "объекта".

, например, если каждый Объект имеет Цвет, Вы могли бы добавить столбец Colour к своей таблице объекта. Матрица и Размер могут использоваться менее часто и могут быть разделены в таблице пары "ключ-значение". Можно даже сохранить цвет в таблице пары "ключ-значение", но копировать данные в таблице объекта для получения выигрышей в производительности.

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

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

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

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

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

, например,

CREATE TABLE valid_keys ( 
    id            NUMBER(10) NOT NULL,
    description   varchar(32) NOT NULL,
    CONSTRAINT pk_valid_keys PRIMARY KEY(id)
);

CREATE TABLE item_values ( 
    item_id NUMBER(10) NOT NULL,
    key_id  NUMBER(10) NOT NULL,
    item_value VARCHAR2(32) NOT NULL,
    CONSTRAINT pk_item_values PRIMARY KEY(item_id),
    CONSTRAINT fk_item_values_iv FOREIGN KEY (key_id) REFERENCES valid_keys (id)
);

можно тогда даже сойти с ума и добавить "ТИП" к ключам, позволив некоторую проверку типа.

Существует другое решение, которое падает где-нибудь между двумя. Можно использовать столбец типа xml для ключей и значений. Таким образом, Вы сохраняете itemid поле, затем имеете xml поле, которое содержит xml, определенный для некоторых пар значения ключа как <items> <item key="colour" value="red"/><item key="xxx" value="blah"/></items> Тогда, когда Вы извлекаете свои данные fro база данных, можно обработать xml различными способами. В зависимости от Вашего использования. Это - расширение способного решения.

Я думаю, что лучший способ создать такие таблицы выглядит следующим образом:

• Сделайте часто используемые поля как столбцы в базе данных.
• Предоставьте столбец «Разное», который содержит словарь (в формате JSON / XML / другой строки), который будет содержать поля в виде пар ключ-значение.

Основные моменты:

• Вы можете написать свои обычные SQL-запросы для запросов SQL в большинстве ситуаций.
• Вы можете выполнить FullTextSearch для пар ключ-значение. MySQL имеет систему полнотекстового поиска, иначе вы можете использовать запросы типа «нравится», которые немного медленнее. Хотя полнотекстовый поиск - это плохо, мы предполагаем, что таких запросов меньше, поэтому это не должно вызывать слишком много проблем.
• Если ваши пары ключ-значение представляют собой простые логические флаги, этот метод имеет те же возможности, что и отдельный столбец для ключ. Любые более сложные операции с парами ключ-значение должны выполняться вне базы данных.
• Если посмотреть на частоту запросов в течение определенного периода времени, вы узнаете, какие пары ключ-значение необходимо преобразовать в столбцы.
• Это Этот метод также упрощает наложение ограничений целостности на базу данных.
• Он предоставляет разработчикам более естественный способ рефакторинга своей схемы и кода.

Однажды я использовал пары ключ-значение в базе данных с целью создания электронной таблицы (используемой для ввода данных), в которой кассир суммировал бы свою деятельность, работая с денежным ящиком. Каждая пара k / v представляет собой именованную ячейку, в которую пользователь вводит денежную сумму. Основная причина такого подхода заключается в том, что таблица сильно подвержена изменениям. Регулярно добавлялись новые продукты и услуги (так появлялись новые ячейки). Кроме того, определенные ячейки не нужны в определенных ситуациях и могут быть отброшены.

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

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

Если нет необходимости извлекать данные по этим атрибутам, либо поиск может быть отложен до приложения после получения фрагмента данных, Я рекомендую хранить все атрибуты в одном текстовом поле (используя JSON, YAML, XML и т. Д.). Если есть острая необходимость в извлечении данных по этим атрибутам, это становится беспорядочным.

Вы можете создать единую таблицу «атрибутов» (id, item_id, key, value, data_type, sort_value), где столбец сортировки покрывает фактическое значение в представление с возможностью сортировки по строкам. (например, дата: «2010-12-25 12:00:00», номер: «0000000001») Или вы можете создать отдельные таблицы атрибутов по типу данных (например, string_attributes, date_attributes, number_attributes). Среди многочисленных плюсов и минусов обоих подходов: первый проще, второй быстрее. И то, и другое заставит вас писать уродливые и сложные запросы.

table (id, item_id, key, value, data_type, sort_value), где столбец сортировки покрывает фактическое значение в представление с возможностью сортировки по строкам. (например, дата: «2010-12-25 12:00:00», номер: «0000000001») Или вы можете создать отдельные таблицы атрибутов по типу данных (например, string_attributes, date_attributes, number_attributes). Среди многочисленных плюсов и минусов обоих подходов: первый проще, второй быстрее. И то, и другое заставит вас писать уродливые и сложные запросы.

table (id, item_id, key, value, data_type, sort_value), где столбец сортировки покрывает фактическое значение в представление с возможностью сортировки по строкам. (например, дата: «2010-12-25 12:00:00», номер: «0000000001») Или вы можете создать отдельные таблицы атрибутов по типу данных (например, string_attributes, date_attributes, number_attributes). Среди многочисленных плюсов и минусов обоих подходов: первый проще, второй быстрее. И то, и другое заставит вас писать уродливые и сложные запросы.

второй быстрее. И то, и другое заставит вас писать уродливые и сложные запросы.

второй быстрее. И то, и другое заставит вас писать уродливые и сложные запросы.