Как Вы разработали бы свою базу данных для разрешения пользовательской схемы

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

Я бы сериализовал пользовательские данные как XML или YAML или JSON или аналогичный полуструктурированный формат и сохраните его в текстовом BLOB.

Вы даже можете создавать инвертированные индексы , чтобы вы могли искать определенные значения среди атрибутов в вашем BLOB. См. http://bret.appspot.com/entry/how-friendfeed-uses-mysql (метод работает в любой СУБД, а не только в MySQL).

Также рассмотрите возможность использования хранилища документов, например Solr или MongoDB . Эти технологии не обязательно должны соответствовать соглашениям о реляционных базах данных. Вы можете добавлять новые атрибуты в любой документ во время выполнения без необходимости переопределять схему. Но это компромисс - отсутствие схемы означает, что ваше приложение не может зависеть от одинаковых документов / строк во всей коллекции.

Я критик анти-паттерна Entity-Attribute-Value.

I ' Я писал о проблемах EAV в своей книге SQL Antipatterns: Избегая ловушек программирования баз данных .

Вот ответ SO, в котором я перечисляю некоторые проблемы с Entity-Attribute-Value: " Таблица продуктов , много видов продуктов, каждый продукт имеет множество параметров ».

Вот блог, который я опубликовал на днях, с дополнительным обсуждением проблем EAV:« EAV FAIL ».

Не как критический комментарий, но может помочь вам сэкономить время, указав, что это один из тех Святых Граалей Дон Кихота тип проблемы. Наверное, уже более 50 лет идет нескончаемый поиск создания удобного интерфейса для проектирования баз данных.

Единственные квази-успешные из них, которые получили сколько-нибудь значительную поддержку, о которых я могу думать, это 1. Excel (и его предшественники), 2. Filemaker (оригинал, а не его текущая версия) и 3. (возможно, но сомнительно) Доступ. Обратите внимание, что первые два ограничены в основном одной таблицей.

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

На первый взгляд, база данных без схемы или документа, такая как CouchDB или SimpleDB для пользовательских данных, кажется идеальной. Но я думаю, это мало поможет, если вы не можете использовать ничего, кроме SQL и EF.

Я не знаком с Entity Framework, но я бы склонялся к Entity-Attribute-Value ( http://en.wikipedia.org/wiki/Entity-Attribute -Value_model ) модель базы данных.

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

Но, как я уже сказал, я не знаю, что Entity Framework должна делать для вас, и, возможно, она не позволит вам использовать этот подход.

Я бы просто дал им копию SQL Server Management Studio и скажите: «с ума сойти!» Зачем изобретать колесо в колесе?

Проверить это сообщение , вы можете это сделать, но это большая тяжелая работа :) Если производительность не является проблемой, xml-решение тоже может работать, хотя это тоже большая работа.

Я бы выбрал гибридную модель сущности-атрибута-значения, поэтому, как и в ответе Антония, у вас есть таблицы EAV, но также есть столбцы по умолчанию (и свойства классов), которые будут существовать всегда.

Вот отличная статья о том, что вас ждет :)

В качестве дополнительного комментария, я создал прототип этого подхода с помощью Linq2Sql за несколько дней, и это было работоспособное решение. . Учитывая, что вы упомянули Entity Framework, я бы взглянул на версию 4 и их поддержку POCO , поскольку это был бы хороший способ внедрить гибридную модель EAV, не загрязняя вашу схему EF.

Давайте попробуем еще раз.

Если вы хотите, чтобы они могли создавать свою собственную схему, то почему бы не построить схему, используя, о, я не знаю, CREATE TABLE статус. У вас есть полноценная, полнофункциональная, мощная база данных, которая может делать удивительные вещи, например определять схемы и хранить данные. Почему бы не использовать это?

Если бы вы просто собирались сделать какие-то специальные свойства, тогда конечно.

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

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

Люди годами создавали «конечных пользователей», «простые» инструменты баз данных.

»

Вместо того, чтобы повторно реализовать оператор sqlservers "CREATE TABLE", что было сделано много лет назад командой программистов, которые, вероятно, были лучше, чем вы или я, почему бы не поработать над раскрытием SQLSERVER в Ограниченный способ для пользователей - позвольте им создать свою собственную схему ограниченным образом и использовать возможности SQLServer, чтобы сделать это правильно.