Padrões / estratégias de design para campos e tipos de dados personalizados

Existem estratégias ou padrões de design comuns para projetar aplicativos que têm a capacidade de adicionar campos personalizados aos objetos de dados ou para criar sua própria definição personalizada de objetos. Por exemplo, estou pensando em produtos como SalesForce, onde você pode ter seus próprios tipos de informações, estruturas como o Expression Engine e a maneira como ele lida com canais e grupos de campos de canais (exemplo) , ou como CMSes Like wordpress tem a capacidade de adicione campos a tipos de postagem personalizados.

Martin Fowler deu uma boa descrição de como modelar propriedades dinâmicas (que é essencialmente o que você está pedindo) em seu livro "Padrões de análise" . A maior parte do conteúdo está disponível online gratuitamente, como artigos em PDF, o que você está procurando é o seguinte:

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

O EAVmodelo é normalmente usado para esquemas não estruturados conforme você descreve.

Ele sofre no desempenho e na capacidade de consultar essas propriedades dinâmicas de maneira ad-hoc ... e, como tal, é considerado por muitos como um antipadrão.

Outras abordagens são usar um formato dinâmico, como XML ou Json, para armazenar essas propriedades, possivelmente com armazenamento dedicado para cada propriedade para ajudar na pesquisa.

Além da tabela EAV que o @Oded descreve, as pessoas usam o banco de dados nosql para esse tipo de informação. Lembre-se de que não há razão para que seu aplicativo não possa usar um banco de dados relacional para as partes que fazem sentido com o modelo relacional e um banco de dados nosql para as informações que não o fazem.

Uma terceira possibilidade é adicionar várias colunas para os campos adicionados pelo cliente (Customerfield1, customerfield2, etc) e fazer com que o cliente defina o que eles significam. Porém, isso funciona apenas para o número de campos configuráveis ​​do cliente que você adiciona; portanto, é bom que você espere que eles precisem de dois ou três, mas não funcionará se você precisar de centenas.

Você não teria o primeiro aplicativo que tinha uma tabela com: UDF1, UDF2, UDF3 ... As outras sugestões (EVA ou NoSQL) são muito melhores.

Dependendo do RDBMS (o SQL Server oferece isso ), você pode sair da normalização e ter um campo que armazena os dados em um formato XML ou apenas texto sem formatação. Você precisará confiar no código para gerenciar isso.