Que estratégia devo empregar usando C # para resolver este caso de uso?

5

Então tudo isso é hipotético e teórico. Este não é um sistema real que eu teria que arquitetar, mas é uma boa pergunta.

Uma empresa armazena e reproduz contratos. Os contratos podem ter muitos documentos associados a eles. Existem até 200 tipos desses documentos que podem ser atribuídos a um único contrato.

É basicamente isso em poucas palavras. Eu não quero escrever 200 classes e ter 200 tabelas de servidor sql em referência a cada tipo de documento. Existe uma solução mais eficiente para coletar os contratos / documentos em um banco de dados e, em seguida, classificá-los em um aplicativo web C # para exibir?

    
por tshoemake 22.12.2016 / 23:57
fonte

2 respostas

4

Como Niklas H escreveu em um comentário enquanto eu digitava isso:

Você tem uma tabela para contratos.

Em seguida, você tem uma tabela de documentos que inclui uma chave estrangeira para as tabelas de contratos do contrato ao qual o documento pertence.

Você então tem uma tabela de tipo de documento onde estão os seus tipos de documento. Da sua tabela de documentos, você tem uma chave estrangeira para a tabela de tipos de documentos, para que você possa armazenar o tipo de um documento.

Isso permitirá que você crie novos tipos de documentos sem precisar criar novas classes. Esses tipos de documento não serão enums.

Você precisará de uma caixa de diálogo no seu sistema onde possa criar novos tipos de documentos, eles provavelmente terão um nome e uma descrição.

Quando você insere um novo documento, seleciona o tipo de documento na lista de tipos de documentos existentes.

    
por 23.12.2016 / 00:04
fonte
1

Pode-se apenas armazenar o próprio documento no banco de dados e não se incomodar com quaisquer outras tabelas em torno de tipos, etc. Os sistemas de documentos mais populares possuem propriedades e metadados associados a ele, então use isso em vez de um sistema predefinido de tabelas. p>

Sua pergunta é bem ampla, mas vamos supor que todos os documentos serão armazenados no banco de dados como PDFs. Mesmo se eles não fossem o processo funcionaria o mesmo. Pode-se ter um conjunto padrão de propriedades / metadados para o documento e, em seguida, ler os dados do próprio documento (PDF) em vez da (s) tabela (s).

Se alguém precisasse pesquisar ou consultar, então extrair essa informação e colocá-la em uma tabela para que possamos escrever consultas contra ela seria útil como mencionado por @Bent e outros.

Você pode até dar um passo adiante e, à medida que o documento é carregado no banco de dados, seu processo examina os metadados do documento, armazena partes importantes desses dados em uma tabela para referência futura e salva o documento e os dados. Você não precisaria de nenhum tipo de tabela de referência porque, conforme os usuários estão carregando documentos, os metadados do documento estão sendo usados para classificar e marcar o documento. Dessa forma, novos tipos são adicionados automaticamente sem a necessidade de manter nenhum desses dados de referência.

Então, uma tabela para o contrato. Uma tabela para documentos. Um contrato / documento de muitos para muitos, se os documentos puderem ser compartilhados entre os contratos. se não for apenas com o FK como mencionado por @Bent.

A tabela de documentos também pode ter as propriedades importantes ou pode ser separada em tabelas de referência separadas.

    
por 23.12.2016 / 17:01
fonte