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

12

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.

design-patterns database-design

— GSto
fonte

6

Você pode estar interessado em ler algumas das respostas para esta pergunta sobre a criação de um banco de dados para campos definidos pelo usuário

— Rachel

É importante notar: a Oracle está processando todo mundo que implementa isso de uma maneira particular (pelo que entendi, comum). Eu daria uma olhada nisso também.

— Steven Evers

6

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

— Doc Brown
fonte

4

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.

— Oded
fonte

Também ouvi falar de pessoas que usam bancos de dados orientados a documentos como uma alternativa ao EAV, mas não têm experiências pessoais com essa abordagem.

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner - Era para isso que eu estava sugerindo, mas como você, nenhuma experiência pessoal.

— Oded

4

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.

— HLGEM
fonte

1

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.

— JeffO
fonte