Шаблони / стратегії дизайну для спеціальних полів та типів даних

12

Чи існують загальні стратегії чи шаблони проектування для проектування додатків, які мають або можливість додавати власні поля до об’єктів даних, або для створення власного власного визначення об'єктів. Наприклад, я маю на увазі такі продукти, як SalesForce, де ви можете мати власні типи інформації, рамки, такі як Expression Engine, і спосіб обробки каналів і груп канальних полів (приклад) , або як Wordpress мають CMSes Like Word додати поля до спеціальних типів публікацій.

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, люди використовують дану базу даних noql для цього типу інформації. Пам’ятайте, що немає жодної причини, через яку ваша програма не може використовувати реляційну базу даних для частин, що мають сенс у реляційній моделі, та носії даних noql для інформації, яка цього не робить.

Третя можливість полягає в тому, щоб додати кілька стовпців для полів, що додаються клієнтом (Customerfield1, customerfield2 тощо), а потім замовник визначить, що вони означають. Це працює лише для кількості зрозумілих для клієнтів полів, які ви додали, хоча це добре, якщо ви лише розраховуєте, що їм знадобиться два-три, але взагалі не працюватимуть, якщо вам знадобиться сотні.

— HLGEM
джерело

1

У вас не було б першої програми, яка мала таблицю з: UDF1, UDF2, UDF3 ... Інші пропозиції (EVA або NoSQL) набагато кращі.

Залежно від RDBMS ( SQL Server пропонує це ), ви можете вийти з нормалізації та мати поле, яке містить дані у форматі XML або просто звичайний текст. Для цього вам доведеться покластися на код.

— JeffO
джерело