Как использовать пару ключ-значение в реляционной базе данных (MySql)? - PullRequest
Новая
       52

Как использовать пару ключ-значение в реляционной базе данных (MySql)?

0 голосов
/ 20 мая 2019

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

  • Я бы получил нет. пар ключ-значение динамически.
  • Я могу создать простую таблицу, чтобы хранить их в отдельных столбцах.
  • Значения могут быть типа int, varchar, text или date.

Проблема, с которой я сталкиваюсь:

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

Как мне этого добиться?

----------------------------------------------- -Редактировать------------------------------------------------ ---

Для большей ясности я предоставляю справочную информацию по этому вопросу, который я разделил на три части: 1. Данные 2: вариант использования 3. Возможные варианты исполнения

1. Данные

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

2. Вариант использования

  1. Покажите разбитый на страницы список лиц, чей ежемесячный доход составляет от 7000 до 10000 долларов. Пользователь может щелкнуть любой номер страницы, и база данных должна напрямую получить данные для этого номера страницы. Например, если мы показываем 10 результатов на странице и пользователь нажимает на 5-й странице, то мы должны показать ему список людей от 40 до 50.

  2. Некоторые значения, относящиеся к определенному описанию группы хранилищ, которые могут иметь большие данные. Поэтому они должны храниться как ТЕКСТ.

3. Возможные варианты исполнения

  1. Я могу создать отдельную таблицу для каждого отдельного типа и сохранить их данные в соответствующих полях. Но проблема, о которой я думаю в этом подходе, заключается в том, что максимальный размер строки в таблице MySQL составляет 65 535 байт. Если придерживаться этого подхода и хранить все данные по горизонтали, это может превысить ограничение максимального размера. Так как количество полей не фиксировано и может изменяться согласно требованию.

  2. Вместо того, чтобы хранить данные по горизонтали, я могу хранить их по вертикали, используя дизайн Entity Attribute Value (пара ключ-значение). На данный момент увеличение количества строк за счет этого дизайна не является проблемой. Используя это, я могу хранить данные обо всех мужчинах, женщинах или детях в одной таблице. Но проблема с этим подходом:

    • Я потеряю тип данных некоторых важных полей. Я не могу запросить и получить список лиц, чей доход превышает 1000.

    • Для хранения данных или всех полей в одном типе значения мне нужно сделать его varchar. Но в некоторых полях хранятся большие данные, для которых требуется тип TEXT.

    Учитывая вышеизложенную проблему, я подумал, что вместо создания только одного поля значения я создам несколько полей значений, таких как value_int, value_varchar, value_date или value_text.

Структура БД

Для этой проблемы я буду использовать MySQL и не смогу изменить БД из-за определенных ограничений. Поэтому я ищу дизайн только с MySQL.

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

1 Ответ

0 голосов
/ 21 мая 2019

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

Например: 

Person (id, name, ...)
Person_demographics (person_id, age, location, ...)
Person_finance (person_id, income, wealth...)

Если вы не заранее знаете сущности и атрибуты, я рекомендую использовать поддержку MySQL JSON. или Поддержка XML . Это дает вам доступ к гораздо лучшим вариантам запросов, чем EAV.

Проблема с EAV-подобными решениями в вашем сценарии заключается в том, что любые нетривиальные запросы оказываются невероятно сложными - «найдите все ответы, где зарплата находится в диапазоне от x до y, а возраст z в местах (a, b»). , c) "превращается в ужасный беспорядок SQL, но с XPath это довольно просто.

...