выбор дизайна для структуры данных, настраиваемой пользователем?

Question

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

Я сталкиваюсь с несколькими техническими возможностями,у всех есть недостатки.:

1. на экранах администратора обновите схему SQL БД, чтобы отразить изменения.
   • Боюсь, что это очень плохая идея из-за разрешений, которые приложение должно иметь на БД.Более того, если при каждом щелчке нужно применять новую схему sql, я думаю, что я буду работать прямо на дыре.Этот подход, который я видел в большинстве приложений, настраивается пользователем.
2. создает в схеме БД набор общих дополнительных столбцов и надеется, что для сложных моделей данных будет достаточно столбцов.
   • это может быстро стать функциональным ограничением, если я не могу разрешить в своем приложении более X столбцов
3. хранить в одной таблице все элементы со столбцом IDи столбец Xml для хранения пользовательских столбцов.
   • этот подход может устранить ранее упомянутые недостатки, поскольку схема sql останется статичной, но поскольку EF (которую я надеялся использовать) не знает, как управлять типом данных xml, мне придетсяв конечном итоге либо вручную SqlCommand с функцией XML, либо написание собственного EF-провайдера, который, я думаю, будет довольно трудоемким.
   • Этот подход, выбранный Microsoft для SharePoint ... позволяет мне думать, что эточем лучше (или, по крайней мере, тем хуже)
4. создать таблицу "свойств", в основном столбец itemId, столбец имени свойства и столбец значения свойства
   • этот подход подразумевает очень очень большую таблицу (X элементов * Y свойств на элемент)
   • Мне придется хранить свои значения в виде простого текста, даже если он числовой, например.

Мои требования:

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

Я чувствую, что выбор правильного дизайна сейчас должен быть удачным, потому что было бы очень трудно изменить этот последний.

Любая обратная связь будет оценена

Answer 1

Одним из вариантов будет использование базы данных NoSQL, такой как MongoDB, которая не содержит схемы. Новые поля не нужно определять заранее (нет головной боли при изменении схемы), и разные записи могут иметь разные поля. Это одно из преимуществ такого NoSQL-магазина.

например. в монго ваша «таблица» может содержать эти две записи в легитимно:

{
    "ID" : 1,
    "FirstName" : "Joe",
    "LastName" : "Bloggs",
    "FavouriteColour" : "Blue"
}

{
    "ID" : 2,
    "FirstName" : "John",
    "LastName" : "Smith",
    "DOB" : "2000-01-01"
}

Добавить в новое поле так же просто, как начать включать его в записи.

По моему опыту, иметь полностью гибкую / динамическую схему в СУБД, такой как SQL Server, может быть немного сложно и сложно для достижения высокой производительности. У меня был опыт с вариантами 1) и 3), которые вы перечислили. Когда данные хранились в формате XML, мне в конечном итоге обычно приходилось все равно разбивать данные на реляционные формы для определенных целей.

Answer 2

Надо сказать, что все, кто обладает полной производительностью, не на 100% реалистичны.

Если вы используете реляционную базу данных, я бы выбрал вариант № 1.У вас все еще есть возможность воспользоваться преимуществами конструкции хранилища, которая делает СУБД быстрой.Вы можете снизить риск для безопасности, используя хранимые процедуры для внесения изменений в DDL, и ограничить права на выполнение для этих SP.

Вариант 2 может быть выполнен, но могут возникнуть проблемы с обслуживанием при попытке выяснить,Цвет виджета хранится в UDFText39 или UDFText52.

Казалось бы, «большой объем данных» исключает вариант 3, если вы не выберете нереляционное решение.В СУБД это будет довольно медленно.

Вариант № 4 - это плохая идея, так как вы вынуждены смешивать не только области данных (цвета, размеры и т. Д.), Но и типы данных.,Держись подальше от этого.

Answer 3

Похоже, это было бы хорошим кандидатом на шаблон EAV (значение атрибута сущности), который похож на одну из описанных вами опций.

Значение атрибута сущности шаблон.

Для дальнейшего чтения на немного более концептуальном уровне вы можете прочитать эту статью> Система атрибутов-значений .

Answer 4

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

Я вижу два неплохих решения:

1) Аналогично вашему 1. решению, используйте 2 таблицы,один с определением столбцов и второй для данных.Например, ваша таблица определений может выглядеть следующим образом:

 Name       Type    Description
 MyColumn1  int     int column
 MyColumn2  string  string column

Таблица данных содержит общие именованные столбцы, заполненные фактическими данными.

Col1    Col2
1      string 1
2       string 2

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

3) Если вы используете MS SQL> = 2008, третье решение выглядит как хорошее.Я все еще рекомендую отдельную таблицу для каждого «типа данных».

Я не рекомендую решение 2, это выглядит как плохой взлом.Решение 4. выглядит чисто, но этот подход не подходит для больших наборов данных.

Answer 5

я бы сказал, что самым чистым решением будет # 4.

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

чтобы у вас не было невероятно огромного стола, и вы одновременно набираете сильные символы. Единственное ограничение: вы ограничены количеством поддерживаемых типов данных. но это ИМХО естественное ограничение.