Как настроить модель данных для настраиваемого приложения - PullRequest
Новая
       1

Как настроить модель данных для настраиваемого приложения

4 голосов
/ 02 сентября 2011

У меня есть приложение ввода данных ASP.NET, которое используется несколькими клиентами.Приложение состоит из нескольких модулей ввода данных, которые являются общими для всех клиентов.

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

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

Я использую SQL Server 2008.

Ответы [ 2 ]

2 голосов
/ 09 сентября 2011

Как всегда с этими вопросами, «это зависит».

Страшная таблица значений ключей.

Этот подход основан на таблице, в которой поля и их значения перечислены в виде отдельных записей. 

CustomFields(clientId int, fieldName sysname, fieldValue varbinary)

Преимущества:

  • Бесконечная гибкость
  • Простота реализации
  • Простота индексации
  • несуществующие значения не занимают места

Недостаток:

  • Отображение списка всех записей с полным списком полей - очень грязный запрос

Путь Microsoft

Microsoft решает проблему такого рода - «разреженные столбцы» (введено в SQL 2008)

Преимущества:

  • Благословенно людьми, которые проектируют SQL Server
  • записи могут быть запрошены без применения причудливых сводок
  • Поля без данных не занимают место на диске

Недостаток:

Налог на xml

Вы можете добавить поле xml в таблицу, которое будет использоваться для хранения всех «лишних» полей.

Преимущества:

  • неограниченная гибкость
  • можно индексировать
  • эффективное хранение (когда оно помещается на странице)
  • При некоторой гимнастике xpath поля могут быть включены в плоский набор записей.
  • Схема может быть применена с коллекциями схем

Недостатки:

  • нечетко видны
  • Поддержка xquery в SQL Server имеет пробелы, которые иногда превращают ваши данные в настоящий кошмар

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

  • значение ключа кажется подходящим, когда количество дополнительных полей ограничено.(скажем, не более 10-20 или около того)
  • Разреженные столбцы больше подходят для данных со многими свойствами, которые заполняются редко.Звучит более уместно, когда у вас может быть много дополнительных полей.
  • xml столбец очень гибкий, но это затрудняет запрос.Подходит для решений, которые пишут редко и редко запрашивают.т.е.: не запускайте агрегаты и т. д. для данных, хранящихся в этом поле.
0 голосов
/ 07 сентября 2011

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

Если есть поля, общие для всех модулей, которые вы добавляете в систему, вам следует рассмотреть вопрос о том, чтобы сохранить их в одной таблице, а затем иметь другие таблицы споля, относящиеся к конкретному модулю, относятся к первичному ключу в общей таблице.В основном это наследование таблиц (h ttp: //www.sqlteam.com/article/implementing-table-inheritance-in-sql-server), которое централизует данные общего модуля и упрощает запросчерез модули.

...