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

Question

Если вам нужно создать приложение, такое как, скажем, приложение блога, создание схемы базы данных относительно просто. Вы должны создать несколько таблиц, tblPosts, tblAttachments, tblCommets, tblBlaBla ... и все (хорошо, я знаю, это немного упрощено, но вы понимаете, что я имею в виду).

Что делать, если у вас есть приложение, в котором вы хотите разрешить пользователям определять части схемы во время выполнения . Допустим, вы хотите создать приложение, в котором пользователи могут регистрировать любые данные. Один пользователь хочет записать свое рабочее время (startTime, endTime, идентификатор проекта, описание), следующий хочет собрать рецепты приготовления, другие, возможно, котировки акций, недельный вес своих детей, ежемесячные расходы, которые они потратили на еду, результаты своих любимые футбольные команды или что-то еще, о чем вы можете подумать.

Как бы вы спроектировали базу данных для хранения всех этих очень разных типов данных? Вы бы создали общую схему, которая может содержать все виды данных, вы бы создали новые таблицы, отражающие схему пользовательских данных, или у вас есть другая отличная идея сделать это?

Если это важно: мне нужно использовать SQL Server / Entity Framework

Answer 1

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

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

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

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

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

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

"Что если они захотят добавить столбец?" Затем добавьте столбец, базы данных делают это, по крайней мере, самые хорошие. Если нет, создайте новую таблицу, скопируйте старые данные, отбросьте старую.

"Что, если они хотят удалить столбец?" Смотри выше. Если вы не можете удалить столбцы, удалите их из логического представления пользователя, чтобы оно выглядело как удаленное.

"Что если у них одиннадцать миллиардов строк данных?" Затем у них есть одиннадцать миллиардов строк данных, а операции занимают в одиннадцать миллиардов больше времени, чем если бы у них был один ряд данных. Если у них есть одиннадцать миллиардов строк данных, они, вероятно, не должны использовать вашу систему для этого.

Увлечение «Реализация баз данных в базах данных» ускользает от меня.

«У меня здесь Oracle, как я могу предложить меньше возможностей и сделать медленнее для пользователя?»

Ну и дела, интересно.

Answer 2

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

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

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

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

---

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

Я написал о проблемах EAV в своей книге, Антипаттерны SQL: предотвращение ошибок при программировании баз данных .

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

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

И обязательно прочтите этот блог " Bad CaRMa " о том, как попытка создать полностью гибкую базу данных практически уничтожила компанию.

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

Answer 8

Ознакомьтесь с этой публикацией , вы можете сделать это, но это очень тяжелая работа :) Если производительность не является проблемой, решение xml тоже может работать, хотя это также много работы.

Answer 9

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