100/200 movimientos diarios es poca cosa. Y me parece un estimado muy bajo. 20.000 clientes (usuarios?) implica potencialmente problemas de contencion dependiendo de cuantos esten actuando a la vez sobre el sistema
MySql como tal (y practicamente cualquier motor de BD) te puede dar la talla, aunque si realmente estas por las opciones open source, Postgres es una opcion mejor en casi todos los aspectos (licencia, tecnologia, estabilidad, flexibilidad, etc), pero principalmente porque postgres tiene una mejor oferta en programabilidad que me parece es insuperable entre las opciones open source.
Con todo, el nucleo de cualquier sistema es mas su diseño/arquitectura que las tecnologias especificas que uses -aunque saber elegirlas es importante, especialmente si te ahorran trabajo, son mas robustas, etc- y tambien el como se hace el despliegue de los servidores (uso de caches, config de hardware, balanceo de cargas, etc).
Aqui es donde tener la experiencia adecuada se notas mas. Es muy facil "machetear" un sistema que parece que funciona cuando no se tiene muy claro las cosas, pero otra es tener un sistema robusto. El que creas que crear bases de datos por año es lo que se necesita para que un sistema sea rapido da mala espina
.
Tienes experiencia de la buena con php/mysql? Si no es asi, con que? Es mejor ir con malo conocido, a menos que tengas bases suficientes para reconocer cuando y porque usar algo nuevo es mejor. Mas importante es como diseñes el sistema, el uso de mediciones para no adivinar que es lo que hace algo rapido/lento.
Imaginate hacer todo el codigo de crear BDs por año, mover saldos, luego descubrir que necesitas hacer consultas a los historicos y todo eso... cuando REALMENTE no hay nada que *demuestre* que eso es necesario. Te sorprenderia lo bien que se mueve una BD con los indices/tablas adecuados y el hardware que es. Si pa' rematar sabes como usar las opciones avanzadas del motor, se puede sacar mucho jugo a un sistema:
http://es.wikipedia.org/wiki/Optimiz...%B3n_prematura
Cita:
|
En informática, el antipatrón de diseño la optimización prematura ocurre cuando un programador permite que las consideraciones de costo en tiempo o espacio afecten el diseño de un componente de software antes de tener un diseño correcto, lo que puede resultar en un diseño más complicado que lo necesario.
|
Tu prioridad #1 es hacer un diseño correcto, luego rapido. Es facil hacer rapido un programa correcto, pero es jodido hacer un programa rapido y luego correcto, y es imposible hacer un bodrio de codigo espaguetti rapido a punta de optimizacion voodo.