none
Performance componente acesso a banco de dados RRS feed

  • Pergunta

  • Boa noite amigos, gostaria de saber se poderiam me dar algumas dicas sobre a seguinte questão:

    Estou atuando em uma aplicação de varejo, com uma previsão de 110 a 115 milhões de requisição por dia.

    Essas requisições vão bater num componente para acessar a base de dados. Nossa equipe está dividia na opinião em utilizar entity, ou procedures para acessar os dados. Eu votei por procedure pois acho que a performance da aplicação cairá muito utilizando entity.

    Poderiam me dar uma sugestão de qual seria a melhor maneira de fazer um acesso a dados performático, considerando esse grande volume de requisições?

    quinta-feira, 12 de junho de 2014 02:06

Respostas

  • Bernoulthy, boa tarde.

    Usar ou não EF ? Usar SPs ? Essas questões estão na vida de muitos desenvolvedores.

    Minha resposta é: Depende...e por que não os dois juntos ?

    Apesar das melhorias feitas no EF nos ultimos tempos, dependendo do que você vai fazer no banco, não justifica deixar de usar procs...e a idéia funciona também no sentido contrário.

    Se você vai executar uma mega query no banco, às vezes a proc vai ser muito bem vinda...

    Se você vai fazer um monte de CRUD no banco...o EF é muito bem vindo pois ele facilita na manutenção (muito mais que usando procs).

    Então amigo, essa pergunta é muito relativa às atividades que seu sistema vai executar. Muitos sistemas usam os dois justamente por conta das facilidades que cada um vai proporcionar.

    Espero que esse texto tenha te ajudado.

    Abraços !


    Diego Murakami View Diego Murakami's LinkedIn profile - MCP, MS, MCSD
    * Por favor "Marcar como Resposta" caso esta for útil para sua dúvida.

    • Marcado como Resposta Bernoulthy terça-feira, 17 de junho de 2014 02:15
    sexta-feira, 13 de junho de 2014 15:19

Todas as Respostas

  • Bernoulthy, boa tarde.

    Usar ou não EF ? Usar SPs ? Essas questões estão na vida de muitos desenvolvedores.

    Minha resposta é: Depende...e por que não os dois juntos ?

    Apesar das melhorias feitas no EF nos ultimos tempos, dependendo do que você vai fazer no banco, não justifica deixar de usar procs...e a idéia funciona também no sentido contrário.

    Se você vai executar uma mega query no banco, às vezes a proc vai ser muito bem vinda...

    Se você vai fazer um monte de CRUD no banco...o EF é muito bem vindo pois ele facilita na manutenção (muito mais que usando procs).

    Então amigo, essa pergunta é muito relativa às atividades que seu sistema vai executar. Muitos sistemas usam os dois justamente por conta das facilidades que cada um vai proporcionar.

    Espero que esse texto tenha te ajudado.

    Abraços !


    Diego Murakami View Diego Murakami's LinkedIn profile - MCP, MS, MCSD
    * Por favor "Marcar como Resposta" caso esta for útil para sua dúvida.

    • Marcado como Resposta Bernoulthy terça-feira, 17 de junho de 2014 02:15
    sexta-feira, 13 de junho de 2014 15:19
  • Olá Bernoulthy,

     assim como disse o Diego, quando fazemos esse tipo de projetos geralmente utilizamos SP e EF, porque com EF fica mais fácil o INSERT, UPDATE, DELETE... Mas quando se trata de consultas muito pesadas utilizo SP com DataReader mesmo e classes para recuperar os dados, com isso os "SELECT" fica mais rádipo, mas quando não se trata de nada complexo o CRUDE todo é feito no EF, mesmo assim não deixamos de utilizar Triggers para alguns casos de Update e Delete com isso tudo se baseia mesmo no seu contexto ! O que vale é mesclar os dois e conseguir otima performance e fácil manutenibilidade !

    sexta-feira, 13 de junho de 2014 18:38