Sugerencia gran base de datos

[JAI_ME]

Buenas tengo un proyecto web para unas escuelas de aproximadamente 80 tablas, tengo pensado hacerlo con php y sqlserver, el problema que veo es que son aproximadamente 500 escuelas, mi duda es como manejar esta información en mi base de datos ya que estoy seguro se pondrá lento al cabo de 1 año, ya que es un año de estar ingresando información todos los días, todas las escuelas.

Se que esos motores de bases de datos son robustos pero es muchísima información.

Tenia pensado crear automáticamente una base de datos con las mismas características (80 tablas) por cada escuela que se registre y manejar su información de forma independiente y usar mysql porque la carga de información se reduce muchísimo y me ahorro lo de la licencia, inclusive también dividir estas bases de datos individuales por años.

es decir
basededatos1-2011, basededatos1-2012.
basededatos2-2011, basededatos2-2012.

Pero en dos años ya serian 800 bases de datos.

Otro inconveniente con este sistema, es que si quiero hacer una consulta general de todas las 400 escuelas no lo podré hacer.


Que me recomiendan.

[_Ruben_]

Supongamos que lo haces todo en una sola base de datos, tendrías 80 tablas, pero ¿qué tablas almacenarían mayor cantidad de registros (por cada escuela)? ¿Que información tendrían esas tablas?

Yo no veo mucho problema, en principio. La base de datos de un foro, por ejemplo, también tiene muchas tablas, que guardan mucha información de muchos usuarios, y solo usan una base de datos.

[JAI_ME]

Hay varias tablas de las 80 que guardan información a diariamente a cada minuto, digamos que 60 de las 80 son de movimiento unas mas que otras, pero realmente que me recomiendan ?

Un foro como este que motor de base de datos utiliza.

[matanga]

Tenia pensado crear automáticamente una base de datos con las mismas características (80 tablas) por cada escuela que se registre y manejar su información de forma independiente..

Si el sistema Web se comporta como un SaaS (Software as a service), es decir, generas una instancia independiente de ejecución del sistema por cada escuela que se registra, entonces también deberías crear una base de datos por cada escuela, esto tiene ventajas como por ejemplo, definir diferentes políticas de backup, almacenamiento, seguridad, optimización, etc en función del uso o tamaño de cada base, la desventaja es el mantenimiento, por ejemplo si una actualización del sistema requiere crear una tabla nueva, lo tienes que hacer en cada base.

..inclusive también dividir estas bases de datos individuales por años.

basededatos1-2011, basededatos1-2012.
basededatos2-2011, basededatos2-2012.

Esto no se recomienda, cuando tienes que dividir los datos, en este caso por años, se debe hacer a nivel de tabla con Partitioning, pero además, no es una decisión que se toma en la fase de diseño del modelo, más bien corresponde a la fase de tuning y solo se implementa en las bases de datos que lo necesiten, hay más info en http://dev.mysql.com/doc/refman/5.6/...titioning.html

Saludos

[Rafael]

Meto la nariz un poco.
Soy un completo ignorante de Bases de datos. Pero por esto mismo para un proyecto que pretende ser muy grande no lo haría yo, sino para eso hay diseñadores de bases de datos, y no me refiero al que haya creado MySql sino quien planea cómo se generan, organizan e interrelacionan los datos, y aparte programadores de bases de datos, para optimizar el proyecto.

[SPAWN3000]

No me preocuparia tanto, Yo trabajo con una base de datos que supera las 6000 tablas y algunas tienen millones de registros, mas de 800 disparadores que de verdad consumen mucho, definicion de reglas, mensajes de respuesta, vistas, tipos de datos, con cientos de usuarios en todo el pais trabajando en forma simultanea, a parte de gran cantidad de procedimientos almacenados, algunos mas pesados se corren en horas de la noche, reportes grandes cargados en cubos, etc... Y algo muy importante es indexar correctamente. Es bueno tener dos instancias y en algunos casos manejar vistas (Como el caso de la tabla de usuarios puede ser una tabla en una base y una vista en otra. Asi tambien la tabla donde se registran datos de personas para evitar duplicidad de informacion...etc). Pero lo que propones es buscar un complicar las labores de mantenimiento, desarrollo, respaldo y seguimiento... Sencillamente no lo hagas. Y procura crear la menor cantidad de tablas posibles (Pero no mas).