Внедрение и индексация пользовательских полей в базе данных SQL - PullRequest
Новая
       28

Внедрение и индексация пользовательских полей в базе данных SQL

3 голосов
/ 21 октября 2009

Мне нужно хранить большую таблицу (несколько миллионов или строк), которая содержит большое количество пользовательских полей (неизвестно во время компиляции, но, вероятно, около 20-40 пользовательских полей). Для меня очень важно (с точки зрения производительности) иметь возможность запрашивать данные на основе этих настраиваемых полей: «выберите строки, в которых этот атрибут имеет это значение, этот атрибут является этим значением и т. Д.». Каждый запрос содержит от 20 до 30 предложений WHERE.

Мои идеи пока:

  1. Изменять схему базы данных каждый раз, когда вводится новое пользовательское поле. Держите каждое пользовательское поле в виде столбца в таблице. Добавить и поддерживать индексы для каждого пользовательского столбца. Как правильно построить эти индексы - большая проблема, так как я не знаю, какие атрибуты (столбцы) будут использоваться в запросах WHERE.

  2. Сохранение пользовательских полей в виде столбца типа XML. Как я понимаю из SQL2005, я могу запрашивать внутри XML в столбцах типа XML. Хотя не уверен в производительности.

  3. Значение атрибута объекта . Это то, что я сейчас использую, но это боль.

Есть предложения?

Edit: Некоторые разъяснения по моим требованиям. У меня есть таблица, 40-50 миллионов строк (скажем) идентификационных номеров и различные атрибуты, связанные с этими идентификаторами.

Допустим, 20 миллионов из них имеют "CustomAttribute1", равный 2, затем 5 миллионов имеют "CustomAttribute2", равный "Да", и 3 миллиона имеют "CustomAttribute20", равный "Нет" 

I need a FAST method of returning all IDs where:
     1. CustomAttribute1  = 2
     2. CustomAttribute2  = 'Yes'
     3. CustomAttribute4  = null
     4. CustomAttribute20  != 'No'  
  etc...

Мы реализовали это как EAV: запрос на выбор - это кошмар для реализации и обслуживания, для возврата результата требуется много времени, и, что самое неприятное, БД масштабируется до огромных размеров даже для небольших объемов данных, что странно, поскольку EAV по существу нормализует данные, но я предполагаю, что все индексы занимают много места.

Ответы [ 2 ]

4 голосов
/ 21 октября 2009

Похоже, вы перечислили доступные варианты. EAV может быть болезненным для запросов (и медленным, в зависимости от того, сколько критериев вы хотите искать одновременно), но это, как правило, наиболее «вменяемая» и независимая от RDBMS реализация.

Изменение схемы - нет-нет ... очевидно, это можно сделать, но такая практика отвратительна. Я не одобряю.

Опция XML является решением, и SQL Server может выполнять запросы внутри структуры. Я не уверен насчет других СУБД, и вы не указываете, какой из них вы используете в посте или тегах.

Если вы собираетесь запрашивать множество атрибутов (скажем, 20+) одновременно, то я, вероятно, рекомендовал бы решение XML только для того, чтобы ограничить количество соединений, которые вы должны сделать. Кроме того, я бы придерживался EAV.

0 голосов
/ 15 мая 2014

Вы можете представить все пользовательские поля в столбце XML, например,

«Но я не уверен, как это повлияет на производительность, однако, на мой взгляд, это, безусловно, самый красивый способ обработки UDF в базе данных». 

   <UDF>
      <Field Name="ConferenceAddress" DBType="NVarChar" Size="255">Some Address</Field>
      <Field Name="ConferenceCity" DBType="NVarChar" Size="255">Some City</Field>
      ...etc
   </UDF>

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

Затем я бы создал хранимую процедуру для обновления XML, чтобы она работала для любого столбца XML после форматирования XML вашего пользовательского поля, например, Вставка / обновление / удаление / Get

GetUDFFieldValue AddUDFField UpdateUDFField DeleteUDFField

- Общие параметры TableName ColumnName (например, используйте динамический SQL, чтобы получить XML из таблицы X по имени столбца X, чтобы сделать его универсальным / универсальным для всех ваших полей UDF)

Вот статья об оптимизации производительности XML из Sql Server 2005 (в более новых версиях отсутствует аналог):

http://technet.microsoft.com/en-us/library/ms345118(v=sql.90).aspx

И наконец:

Вы уверены, что вам даже нужна СУБД? NoSql Лучше подходит для пользовательских полей, я мог бы даже подумать об использовании как NoSql, так и Sql Server.

...