Atualmente estou com um projeto que "herdei" assim que entrei na empresa. O projeto tem algumas coisinhas bacaninhas, uma delas é um wizard onde o usuário monta as consultas no banco de dados, fazendo assim com que tenha uma grande flexibilidade a aplicação, porque seu uso basicamente consiste em consultar informações "coletadas".
Esta flexibilidade faz com que cada setor que comece a usar a aplicação, tenha a possibilidade de suprir suas necessidades criando as consultas que satisfazem suas necessidades diárias de informações. Porém, nem tudo são flores na vida de Joseph Klimber.... =)
Atualmente estamos com um sério problema que é a alta carga de processamento e alto "I/O Wait" no servidor. Isto é ocasionado pela fragmentação do banco de dados, mas principalmente por queries mal feitas. Porque? Porque estas queries são geradas por um wizard, e normalmente as queries não retornam menos de 10mil registros, então, juntando estas queries com a fragmentação da base, nos temos um alto I/O.
Como eu sou um cara eficaz (eficiente ou eficaz? essa é pro pessoal da wise), peguei as queries do sistema e tentei dar um trato, "tunnando" o que dava, porém cheguei na parte das queries pesadas do banco de dados, que eram aquelas consultas. Então me deparei com o problema que é o seguinte, como vou "tunnar" uma query que muda a toda hora? E mesmo que consiga estas principais, como ficarão as outras novas assim que o suporte acabar!?
Este foi um exemplo para que eu pudesse chegar ao ponto que queria, que é: Até onde flexibilidade realmente ajuda?
Deixar o usuário fazer o que quizer, ou deixar a aplicação "redondinha"? Por enquanto ainda acho que as duas coisas são inversamente proporcionais.
O que acha você?
quarta-feira, 2 de maio de 2007
Até que ponto a flexibilidade é boa?
Postado por
Unknown
às
08:41
6
comentários
Marcadores: arquitetura, database, flexibilidade, server
quinta-feira, 5 de abril de 2007
XPTO-Driven Design
A cada dia que passa, surge uma nova metodologia, algumas como:
- Test-Driven Design
- Model-Driven Design
- Specification-Driven Design
- etc...
O que me vem a cabeça vendo tudo isso hoje, é simplesmente que: isso tudo já existe, você já faz tudo isso, porém alguém, aproveitando-se da "onda" lança um nome para um modo de fazer as coisas, que eu acho que mais confundem do que ajudam. Ou seja, você já faz isso, já usa isso no seu dia-a-dia, porém, você apenas não batizou o esquema. É igual a dar nome pro seu pênis =)
Verdade, eu fico impressionado porquê a galerinha tem imaginação pra caramba.
É claro que cada projeto requer um tipo de abordagem pra se chegar no resultado final, o que não pode é forçar uma abordagem porque ela está em alta. Hoje, a que mais se fala é Model-Driven Design, bem bacana, faça seu modelo consistente e depois trabalhe o resto (simplóriamente). Eu não estou aqui dizendo que isso está errado, que a metodologia está errada, apenas o que quero dizer é que as vezes o marketing pode atrapalhar desenvolvedores, porque se você ouve muito falar em uma coisa, com certeza, você irá querer conhece-la e na maioria dos casos aplicá-la. Muitas vezes adaptando o projeto a metodologia, e não escolhendo a melhor metodologia para o projeto.
Esse é o meu maior medo quando ouço falar de uma coisa nova deste tipo.
Sei que esse post, pode ter ficado meio desconexo, com frases meio soltas, o que acontece é que na verdade ainda não formei uma opinião real sobre isso, e sim, estou divagando sobre o assunto enquanto escrevo, por isso gostaria de mais opiniões sobre o assunto.
O que acha sobre isso?
Postado por
Unknown
às
12:15
1 comentários
Hail!!
Buenas a todos.
Apartir de hoje, começarei a escrever neste blog. A finalidade será basicamente manter um blog voltado a tecnologia em geral com eventuais posts sobre assuntos diversos.
Vamos aos posts então...
Postado por
Unknown
às
12:08
0
comentários