Шаблоны проектирования / стратегии для пользовательских полей и типов данных

12

Существуют ли какие-либо общие стратегии или шаблоны проектирования для разработки приложений, которые могут либо добавлять настраиваемые поля в объекты данных, либо создавать собственные настраиваемые определения объектов. Например, я имею в виду такие продукты, как SalesForce, где вы можете иметь свои собственные типы информации, такие как фреймворк Expression Engine и способ его обработки каналов и групп полей каналов (Пример) или как CMS, такие как wordpress, могут добавить поля для пользовательских типов сообщений.

design-patterns database-design

— GSto
источник

6

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

— Рэйчел

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

— Стивен Эверс

6

Мартин Фаулер дал хорошее описание того, как моделировать динамические свойства (что, по сути, является тем, о чем вы просите) в своей книге «Шаблоны анализа» . Большая часть контента доступна онлайн бесплатно в виде статей в формате PDF, вот что вы ищете:

http://martinfowler.com/apsupp/properties.pdf

— Док Браун
источник

4

EAVМодель обычно используется для неструктурированных схем , как вы описываете.

Он страдает от производительности и способности запрашивать такие динамические свойства специальным образом ... и, как таковой, многие считают его антипаттерном.

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

— Одед
источник

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

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner - это то, на что я намекал, но, как вы, никакого личного опыта.

— Одед

4

В дополнение к таблице EAV, которую описывает @Oded, люди используют базу данных nosql для этого типа информации. Помните, что нет причины, по которой ваше приложение не может использовать реляционную базу данных для частей, которые имеют смысл с реляционной моделью, и базу данных nosql для информации, которая этого не делает.

Третий вариант - добавить несколько столбцов для полей, добавленных клиентом (Customerfield1, customerfield2 и т. Д.), А затем попросить клиента определить их значение. Это работает только для тех полей, которые вы добавляете, поэтому хорошо, если вы ожидаете, что им понадобятся два или три, но не будут работать вообще, если вам понадобятся сотни.

— HLGEM
источник

1

У вас не будет первого приложения с таблицей: UDF1, UDF2, UDF3 ... Другие предложения (EVA или NoSQL) намного лучше.

В зависимости от РСУБД ( SQL Server предлагает это ), вы можете выйти из нормализации и иметь поле, которое содержит данные в формате XML или просто в виде простого текста. Вам придется полагаться на код для управления этим.

— JeffO
источник