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

Question

Допустим, вы разрабатываете приложение, которое по требованию позволяет пользователю гибко создавать пользовательские типы (для управления своими данными, какими бы они ни были). Одним из способов решения этой проблемы является определение схемы, которая позволяет нам использовать метаданные для определения этих типов. Это часто означает, что полученная схема БД будет иметь некоторый способ хранения пар ключ / значение (свойства, принадлежащие экземпляру типа), где часть значения обычно хранится в виде строки (независимо от основного типа данных столбца). Это само по себе представляет ряд проблем. Я читал, что некоторые осуждают , используя db для отслеживания пар ключ / значение.

Основная проблема, с которой я столкнулся, заключается в том, как это влияет на запросы. Например, предположим, что пользователь хочет создать тип с именем Event, имеющий следующие столбцы: event_name, description, start_at и end_at (datetime). Использование пар ключ / значение, где все значения являются строками, делает запросы более чувствительными к тому, как форматируются значения параметров; следовательно, запрос набора событий, попадающих между двумя датами, не так прост, как если бы мы использовали фактические столбцы datetime.

Это побуждает меня рассмотреть альтернативные проекты, которые бы приспособили нестандартные типы. Первое, что пришло на ум и которое мне понравилось больше всего, - это использовать саму базу данных для определения этих пользовательских типов. То есть вместо того, чтобы создавать отдельный набор мета-таблиц, в которых должны быть определены все типы, просто дайте пользователю ограниченную привилегию создавать / изменять свои собственные таблицы в базе данных (все из которых будут иметь префикс с его именем пользователя: например, usertable-johndoe-album). Наиболее заметная проблема, с которой я сталкиваюсь при таком подходе, - это огромное количество таблиц, которые в конечном итоге могут существовать. Интересно, есть ли у большинства баз данных с открытым исходным кодом (MySQL, Postgres и т. Д.) Жесткое или практическое ограничение на количество таблиц, которыми они могут управлять, не создавая препятствий. То есть я знаю, что большинство готовых к работе баз данных настроены на обработку миллионов записей, но я не знаю, оснащены ли они для обработки сотен тысяч таблиц. Кто-нибудь знает?

Учитывая требование разрешить пользователям создавать свои собственные типы, вы предпочитаете пары ключ / значение или используете саму базу данных? Или, если у вас есть другая модель / идея, опишите ее.

Answer 1

Я сомневаюсь, что вы достигнете максимального предела таблицы, поскольку они обычно связаны с ограничениями ОС, а не с ограничениями СУБД. Однако существует альтернативный подход к моделированию, называемый EAV model , который в основном является общим способом описания пользовательских объектов и связанных столбцов (атрибутов). Есть некоторые недостатки, но, похоже, это хорошо подойдет для ваших нужд.

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

Answer 2

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

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

Пример:

При цифровой обработке в вашей системе могут быть «объекты», подключенные к физической линии / контроллерам / счетчикам. Допустим, один объект подключен к измерителю температуры, поэтому объект показывает текущую температуру. Тип, из которого был создан объект, содержит ряд аспектов (вроде свойств объекта), одним из таких аспектов может быть, например, отображение для отображения значения - temp. в этом случае. Каждый раз, когда пользователь хочет подключить темп. счетчик, он будет создавать экземпляр объекта такого типа и настраивать его для подключения к физическому счетчику (используя аспекты).

Теперь, если конечный пользователь может захотеть сделать что-то еще, скажем, он хочет добавить график, показывающий временную шкалу. для последних 24-часовых чтений (история) - при условии, что для этого есть аспект - он может создать новый тип, унаследовав от ранее упомянутого типа, и добавить аспект истории в новый тип. Так что он сделал, он создал новый тип. Затем он может вместо использования исходного типа использовать этот новый тип при создании экземпляра temp. объект. Это позволяет очень динамично обрабатывать типы.

Answer 3

Что касается вашей второй идеи (предполагается, что при создании usertable-johndoe-album ее структура является зеркалом базовой таблицы base-album): Я бы сказал, что НЕ создавайте новые таблицы для каждого пользователя. В противном случае, если вам придется изменить базовую структуру таблиц в будущем (возможно, для исправлений обслуживания), вам придется распространить то же самое изменение на ВСЕ таблицы, созданные пользователями. Возможно, вам удастся найти умный способ автоматизировать это, но он все еще открывает двери для гораздо большего количества потенциальных проблем, IMO (не включая жесткие верхние пределы для номеров таблиц).

Я думаю, что метатаблицы - лучший способ приблизиться к этому. Может быть возможно автоматически создавать представления для типов, которые определяет пользователь, это может упростить запрос метаданных. Вы также можете рассмотреть возможность иметь больше, чем просто ключи и значения в таблице ключ / значение. Наличие идентификатора пользователя позволит вам индексировать по идентификатору пользователя, что может помочь с проблемами производительности.

Answer 4

«Учитывая требование разрешить пользователям создавать свои собственные типы»

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

"или используя саму базу данных" В некотором смысле.

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

---

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

У вас есть материал для поддержки ваших встроенных типов.

У вас есть инструменты и утилиты, которые будут поддерживать дополнительные типы расширений.

«Пользователи» просто подключают свой код к вашей инфраструктуре.

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

Поскольку вы создаете фреймворк, попробуйте и упростите вещи, чтобы программисты могли без труда добавлять свои собственные типы.