Al rededor de dos millones de registros anuales

[Carxl]

Hola, cómo vamos?

Bueno tengo ahora que desarrollar un sistema web que podría contener 2 millones de registros anuales y sumémosle la cantidad de info que ya hay hace 8 años.

Debido a esto, quisiera conocer buenas prácticas para dicho desarrollo, por ejemplo que, usar procedimientos almacenados es mejor?

Cualquier consejo para este tipo de volumen de información es bienvenida.

Pienso realizar dicho sistema bajo Windows, Postgres y Php.

Gracias!

[tepitenio]

Stored Procedures OBVIO Que si, eso acelera mucho el acceso a la DB

Por otro lado te recomendaría un server Linux (si pueden pagar un RedHat también lo recomiendo)

Si buscas MUCHA velocidad, parametriza lo MENOS posible, y HARDCODEA lo mas posible.

[Carxl]

Hola tepitenio, gracias por tu respuesta :)

Si buscas MUCHA velocidad, parametriza lo MENOS posible, y HARDCODEA lo mas posible.

Me podrías por favor redondear esa idea? puntualizando?

Gracias

[tepitenio]

El punto es que uno cae fácil en la tentación de parametrizar el sistema y eso, cuando se trabaja con grandes cantidades de datos, puede ralentizar mucho.

Por ejemplo, si tienes un campo "Tipo de Pago", con la posibilidad de poner EFECTIVO, CHEQUE, CRÉDITO, FIADO (aajajaja), en lugar de hacer un vector o una función hardcodeada, lo metemos en una tabla. Con la consecuencia que luego los queries tienen que relacionarla también, y eso en millones de registros ralentiza.

Otro consejo: Divide las tablas en tipos de datos.

Digamos que tienes cliente:

Nombre, Apellido, Titulo, Id, Pasaporte, Tipo de Pago, Tarjeta de Crédito, Telefono Personal, Telefono Laboral, Movil, Fax, Telex, Mail, SitioWeb, Oficina, Casa, etc.

lo que conviene hacer es hacer una tabla CLIENTE, que tenga nada mas que Id, Nombre, Apellido. Luego otra tabla CLIENTE_PAGO que tiene Id, TipoPago, TCredito. Otra tabla CLIENTE CONTACTO que tiene Id, Telefonos, Movil, Mail, SitioWeb. Otra CLIENTEPOSTAL etc ect

Entonces los queries se hacen con tablas relativamente pequeñas.

[eriksoft]

Iniciado por tepitenio

El punto es que uno cae fácil en la tentación de parametrizar el sistema y eso, cuando se trabaja con grandes cantidades de datos, puede ralentizar mucho.

Por ejemplo, si tienes un campo "Tipo de Pago", con la posibilidad de poner EFECTIVO, CHEQUE, CRÉDITO, FIADO (aajajaja), en lugar de hacer un vector o una función hardcodeada, lo metemos en una tabla. Con la consecuencia que luego los queries tienen que relacionarla también, y eso en millones de registros ralentiza.

Otro consejo: Divide las tablas en tipos de datos.

Digamos que tienes cliente:

Nombre, Apellido, Titulo, Id, Pasaporte, Tipo de Pago, Tarjeta de Crédito, Telefono Personal, Telefono Laboral, Movil, Fax, Telex, Mail, SitioWeb, Oficina, Casa, etc.

lo que conviene hacer es hacer una tabla CLIENTE, que tenga nada mas que Id, Nombre, Apellido. Luego otra tabla CLIENTE_PAGO que tiene Id, TipoPago, TCredito. Otra tabla CLIENTE CONTACTO que tiene Id, Telefonos, Movil, Mail, SitioWeb. Otra CLIENTEPOSTAL etc ect

Entonces los queries se hacen con tablas relativamente pequeñas.

Hola a todos ademas de todo eso y como han explicado antes el modelado de la base de datos es la parte importante para todo sistema informático. en tipo de programación que usaras (estructurada o POO) en el caso de usar PHP podrias usar algún Framework como por ejemplo ZEND o alguno que te ayude con la programacion y te agilice los procesos.

[wwwmaster]

Requeriria conocer mas las caracteristicas del proyecto, pero si un cliente me solicitara una recomendacion para albergar 2 millones de registros x año, primero le recomendaria que eligiera como base datos: DB2 (Ibm), Informix, u Oracle.

DB2 me ha permitido manejar tablas de 4 millones de registros sin mayor problema... claro.. ejecutandose en un equipo iSeries.. nada barato.

Luego me precuparia x que la base de datos estuviera normalizada, y manejar la informacion en las tablas mensuales si se requiriera para que estuvieran debidamente separadas.