Я могу придумать три решения - EAV, XML и Sparse Columns. Последнее зависит от поставщика и может оказаться бесполезным для вас.
Какой бы метод вы ни выбрали, вы можете рассмотреть возможность сохранения исходных данных запроса в необработанном формате, в виде таблицы или плоского файла. Это позволит легко опробовать новые способы хранения данных, позволит перезагрузить данные, если вы обнаружите ошибку при анализе ваших запросов, и предложит возможности для анализа запросов API с помощью пакетной обработки или «больших данных». инструменты, если вы обнаружите, что ваше хранилище данных не в состоянии эффективно обрабатывать данные.
EAV соображения
EAV / KVS, как вы описали выше, вероятно, будет самой простой реализацией.
К сожалению, это также будет очень дорого - чтобы получить любые эффективные запросы по часто используемым ключам, вам понадобятся индексы для ключевого столбца, которые могут быть очень фрагментированными. Запрос конкретных ключей будет чрезвычайно дорогим.
Вы можете уменьшить стоимость индексирования или сканирования индекса, поддерживая свое хранилище EAV материализованными представлениями (многие поставщики поддерживают это) для запроса ключей или значений, которые вас интересуют.
XML
Большинство систем баз данных предприятия предлагают очень зрелую обработку XML, включая проверку, индексацию и сложные запросы.
Загрузка запроса API в базу данных в виде XML обеспечит один кортеж на запрос, что логически может быть более приемлемым для вас, чем наличие неизвестного количества строк в таблице EAV.
Эффективность этого будет во многом зависеть от вашего поставщика RDBMS и вашей реализации.
Самым большим недостатком является то, что это, вероятно, единственный способ управления данными, который является более сложным, чем манипуляции со строками исходного запроса!
Разреженные столбцы / традиционные таблицы
Возможно, вы могли бы загрузить свои данные в традиционную структуру таблицы, с одним столбцом на ключ.
Функция Sparse Columns в SQL Server - отличная альтернатива хранилищу EAV. Таблица с разреженными столбцами ведет себя так же, как обычная таблица, за исключением того, что она может содержать до 30 000 столбцов, а значения NULL в разреженных столбцах не занимают места в таблице.
Объединение их с отфильтрованными индексами (еще одна особенность SQL Server) может обеспечить чрезвычайно эффективную альтернативу хранилищу EAV, если вы часто запрашиваете пару конкретных столбцов и / или значений.
Использование традиционной таблицы с другими поставщиками может быть целесообразным - IBM поддерживает более 700 столбцов на таблицу, а Oracle - около 1000, а такие функции, как сжатие или обработка завершающих нулей Oracle, могут означать, что вы можете хранить свои данные API довольно эффективно.
Очевидный недостаток этого подхода заключается в том, что по мере добавления новых ключей в API вам необходимо соответствующим образом изменить свою схему.