none
Eu e minhas idéias doidas... RRS feed

  • Discussão Geral

  • Boa noite pessoal,

    Acredito que seja a primeira vez que posto em um fórum oficial da MS. Na verdade, já fazem alguns anos que não posto em fórum algum, costume este que pretendo retomar, começando agora.

    Como assunto deste meu retorno, gostaria de colocar na roda minhas pirações dos ultimos mêses os quais estive envolvido em um emaranhado de tecnologias e plataformas para desenvolver um portal que dentre outras coisas possui mapas (estilo google maps, com toda a infra local [load balance, geometrias, etc]), muito javascript (envolvendo inclusive Google Gears), Python, Eiffel e até Raskel.

    Estou tentando manter uma rotina de ir anotando as doideiras que me ocorrem pra solucionar estes casos no neu blog (link no fim do post), e pra não ficar na propaganda, aí vai um dos assuntos que mais me envolvi (vou postar aqui pra só entrar no blog quem animar com a idéia).



    Kill it with fire!

    Imagine você a possibilidade da implementação do banco de dados seguindo as bases de uma arquitetura MVC, onde para uma aplicação qualquer teríamos no mínimo três bancos diferentes, cada qual com sua aplicabilidade, e importante em sua respectiva finalidade seja ela a de:

    • exibir/retornar (view);
    • inserir/atualizar/excluir (controller);
    • ou guardar/manter(model) os dados

    Humm.. Até que faz algum sentido

    Pois é, alguém tem que fazer o papel de maluco e propor coisas doidas do gênero… Esta proposta em especial surgiu da necessidade de se manter a organização e força dos relacionamentos de um banco de dados relacional normalizado, porém, proporcionando de alguma forma subsídios para que a aplicação possa obter estes dados e informações com o menor esforço e no menor tempo possível.

    Se você leu meu post anterior sabe que estou atualmente em busca de encontrar um formato arquitetural que me permita desenvolver componentes burros que consigam desempenhar perfeitamente (ou o mais próximo disto) a tarefa a qual é destinado, ignorando quase que por completo o meio em que habita. Seguindo este conceito, diria que um banco de dados, seja ele destinado a qualquer aplicação, deve única e exclusivamente conter e guardar o dados, como o nome sugere, porém, é impossível ou melhor dizendo, é absurdo querer retirar toda e qualquer marcação de relacionamento que é o que basicamente separa um banco de dados relacional de uma coleção de arquivos .txt guardados em disco.

    Ok, com isto em mente, como então separar e fazer com que o banco de dados seja meramente um repositório de dados em sua essência?! Ao ler as linha abaixo na primeira vez isto pode acabar ficando um tanto quanto confuso, mas se dê um tempo e tente novamente… Acho que vale a pena.

    O paradigma

    A descrição básica deste paradigma é simples: A aplicação deverá sempre atuar sobre o Banco de dados Controller, o qual devera propagar as ações requisitadas pelo cliente para a Model e preparar a View para exibir performaticamente os dados manipulados pelo contexto.

    Abaixo, um diagrama com as macro responsabilidades e restrições de cada porção do modelo:

     

    Modelo básico de responsabilidades

    Modelo básico de responsabilidades

    Para um melhor entendimento dos tópicos acredito que é valido fazer um breve descritivo sobre cada um deles:

    • Model
      • Altamente normalizado
        • Simples como a expressão define: Os dados desta base devem ser altamente normalizados e permanecer organizados com o máximo de aderência possível a uma estrutura lógica plausível.
      • Dados up-to-date
        • Os dados da model devem refletir o último estado, as alterações e informações mais recentes SEMPRE .
      • Não possui triggers/ Stored Procedures / Functions/ Jobs
        • A Model não deve possuir qualquer objeto que contenha negócio, independente do contexto / motivo / necessidade. Estas ações devem ser gerenciadas e concentradas na base Controller
    • Controller
      • Apenas dados de cache / log / trace / etc
        • A camada Controller não será consultada para exibição de dados, logo, qualquer dado que exista na mesma deve ser tratado como contextual e/ou relativo à gestão do processo como um todo ao exemplo de logs de execução.
      • Desnormalizado
        • Pelo motivo acima, qualquer dado que seja gravado não necessariamente estará normalizado
      • Possui triggers / functions / stored procedures / Jobs / CLR / etc
        • Como principal função, o Banco Controller executa queries contra os BDs Model e View de forma a dispor e organizar os dados em estruturas que visão facilitar a manipulação dos mesmos
    • View
      • Prioritariamente dados up-to-date
        • A priori, os dados são exatamente os dados constantes na base Model
      • Altamente desnormalizado (performático)
        • Dados sempre prontos para exibição/consulta com o mínimo possível de JOINS
      • Possui Stored Proc / Views / functions  – APENAS SELECT
        • Tá explicado… Tudo é liberado, para SELECTs
      • Não possui Jobs
        • O trabalho de alimentar e organizar as tabelas é da controller

    Bom, acho que deu pra entender a viagem…

     



    Digam ae o que acharam da idéia, dúvidas, coisas do genero....

    Link pro blog: http://iguessimnotcrazy.wordpress.com/

    Abraço à todos!
    quinta-feira, 24 de setembro de 2009 00:08

Todas as Respostas

  • Kara tudo muito bonito e bacana...

    mais insira disponibilidade ai  crie um cluster

     

    pois se um unico db ai cair  ...sua aplicação muito arquitetada vai para


    Gabriel Felix MCITP
    quarta-feira, 25 de janeiro de 2012 20:03
  • Cara, é até interessante, e como seria a comunicação entre os bancos?

     

    Isso seria muito interessante de implementar em algum banco NoSQL orientado a objetos


    Pedro Henrique B. Fernandes
    MCTS - .NET Framework 4, Data Access
    MCTS - .NET Framework 4, Web Applications
    Site: pedrofernandes.net
    quinta-feira, 26 de janeiro de 2012 00:46