Quais são os princípios e benefícios do "modelo do partido"?
o " modelo do partido "é um" padrão " para o desenho de bases de dados relacionais. Pelo menos uma parte dele envolve encontrar a comunalidade entre muitas Entidades, tais como cliente, empregado, parceiro, etc., e factoring that into some more "abstract" database tables.
gostaria de saber o que pensa sobre o seguinte:
-
Quais são os princípios fundamentais e as forças motivadoras por trás do modelo do partido?
O que lhe prescreve o seu modelo de dados? (Minha parte acima é bastante alto nível e muito possivelmente incorreto em alguns aspectos. Eu estive em um projeto que o usou, mas eu estava trabalhando com uma equipe separada focada em outros assuntos).
O que a sua experiência o levou a sentir sobre isso? Usaste-o e, se assim fosse, voltavas a fazê-lo? Quais eram os prós e os contras?
O modelo do partido limitou a sua escolha de ORMs? Por exemplo, você teve que eliminar certos ORMs porque eles não permitiram o suficiente de uma "camada de abstração" entre o seu objectos de domínio e o seu modelo de dados físicos?
6 answers
Na medida em que o usei, trata-se principalmente de reutilização de código e flexibilidade. Já o usamos antes no modelo guest / user / admin e ele certamente prova o seu valor quando você precisa mover um usuário de um grupo para outro. Estender isso para ter organizações e empresas representadas com usuários sob eles, e está realmente fornecendo uma forma de abstração que não é particularmente inerente ao SQL.Quais são os princípios fundamentais e as forças motivadoras por trás do partido? modelo?
Tens razão na parte de cima, mas precisa de mais detalhes. Você pode imaginar uma situação em que uma entidade na base de dados (chamá-lo de parte) contrata para outro Parte, que pode, por sua vez, subcontratar o trabalho. Uma festa pode ser um empregado, um empreiteiro, ou uma empresa, todas as subclasses de festa. Do meu entendimento, você teria uma tabela do partido e, em seguida, tabelas mais específicas para cada subclasse, que poderia então ser mais subclassificado (Partido -> pessoa -> contratante).O que lhe prescreve o seu modelo de dados? (A minha parte acima é muito alto nível e muito possivelmente incorrecto em alguns aspectos. Estive num o projecto que o usou, mas eu estava trabalhar com uma equipa separada focada outros aspectos).
O que a sua experiência o levou a sentir sobre isso? Usaste-o, e se então, voltarias a fazê-lo? O que foram os prós e os contras?
Tem seus benefícios se você precisar de forma flexível para adicionar novos tipos ao seu sistema e criar relações entre tipos que você não esperava no início e arquiteto em (usuários se movendo para um novo nível, empresas contratando outras empresas, etc). Ele também lhe dá o benefício de executar uma única consulta e recuperar dados para vários tipos de partes (empresas,funcionários,empreiteiros). No outro lado, você está adicionando camadas adicionais de abstração para chegar aos dados que você realmente precisa e está aumentando carregar (ou pelo menos o número de junções) na base de dados quando você está pesquisando por um tipo específico. Se a sua abstração for longe demais, você provavelmente precisará executar várias consultas para recuperar os dados como a complexidade iria começar a se tornar prejudicial para a legibilidade e carga de banco de dados.
O modelo do partido limitou a sua escolha de ORMs? Por exemplo, você têm de eliminar certos ORMs porque eles não permitiram o suficiente de um "camada de abstracção" entre a sua dominio objectos e seus dados físicos modelo?
Esta é uma área em que admito que sou um pouco fraco, mas descobri que usar vistas e abstração espelhada na camada de aplicação não fez isto muito de um problema. O verdadeiro problema para mim sempre foi um "onde está o pedaço de dados X vida" quando eu quero ler a fonte de dados diretamente (nem sempre é intuitivo para novos desenvolvedores no sistema).
Prós:
- a escalabilidade horizontal do Kick-ass. Uma vez que suas mesas 5-6 são definidas em seu modelo de entidade, você pode ir para a praia e beber margaritas. Você pode virtualmente dimensionar esta base de dados tanto quanto quiser com o mínimo de esforços.
- a base de dados suporta qualquer estrutura de dados que você atira. Você também pode alterar estruturas de dados e definições de partes/entidades no momento sem afetar sua aplicação. Isto é muito poderoso.
- pode modelar qualquer entidade de dados arbitrária adicionando registos, não alterando o esquema. Significa que podes dizer adeus aos programas de migração do esquema. Este é o paraíso dos programadores, uma vez que o código que eles escrevem irá definir as entidades reais que eles usam em código, e não há mapeamentos de objetos para tabelas ou algo assim. Você pode pensar na Tabela Do Partido como o objeto base de sua estrutura de escolha (Sistema.Objecto do .NET)
Conts:
- Os modelos Partido / entidade nunca brincam bem com os ORMs, por isso esqueçam o uso de EF ou NHibernate para tirar entidades semanticamente significativas da vossa base de dados de entidades.
Muitas juntas. Desafios de ajuste de desempenho. Este ' con ' é relativo às práticas que você usa para definir suas entidades, mas é seguro dizer que você estará fazendo muito mais desses perguntas que te trazem pesadelos à noite.
Mais difícil de consumir. Desenvolvedores e DB pros não familiarizados com o seu negócio terá um tempo mais difícil para se acostumar com as entidades expostas por estes modelos. Uma vez que tudo é abstrato, não há diagrama ou visualização que você pode construir em cima de sua base de dados para explicar o que é armazenado para outra pessoa.
([6]) serão necessários modelos de acesso a dados pesados ou motores de regras de Negócio. Basicamente você tem que fazer o trabalho de compreensão o que você quer de seu banco de dados em algum momento, e seu modelo de banco de dados não vai ajudá-lo desta vez.
Se está a considerar um esquema de uma parte ou entidade numa base de dados relacional, deve provavelmente dar uma vista de olhos a outras soluções como uma loja de dados NoSql, lojas BigTable ou KV. Há alguns grandes produtos lá fora com implementos maciços e tração, como MongoDB, DynamoDB, e Cassandra que foi pioneira neste movimento.
Todas as partes têm muitas propriedades em comum. O fato de que eles têm um nome e tal (nós chamamos aqueles "signaléticos"). O fato de que eles têm locais principais / primários chamados "endereços". O facto de todos eles estarem envolvidos, de certa forma, nos contratos das empresas.
Este é um vasto tópico, Eu recomendaria a leitura {[[2]} do Livro de recursos do modelo de dados Volume 3 - padrões universais para modelagem de dados por Len Silverston e Paul Agnew.
Acabei de receber a minha cópia e é muito bom - ela fornece-lhe um overlook para muitas abordagens de modelagem de dados, incluindo padrões de papel contextual híbrido e assim por diante. Tem prós e contras detalhados para cada abordagem. Há uma infinidade de formas de modelar relações partidárias e papéis. com os seus benefícios e desvantagens. A pergunta que foi aceite como resposta abrange apenas um exemplo de um "modelo partidário".Por exemplo, em muitas abordagens, noções como "empregado"," Gestor de projecto " etc. sãopapéis que uma parte pode desempenhar dentro de um determinado contexto. Vou tentar dar-te um esgotamento melhor quando chegar a casa.
Como uma simples conversa do meu entendimento: modelo de festa dá a flexibilidade e precisa de mais esforço (como T-sql join e ...) a implementar.
I also wanna point that, "using Party modeling (serialization/generalization) gives you the ability to have FK-Relation to other tables". por exemplo: pense em diferentes tipos de usuários (Administrador, Usuário, ...) que se generalizaram na tabela {[[0]}, e você pode ter UserID na sua tabela Authorization.