#30 En cuanto a escalabilidad, manejo de grandes bbdd, rollback, comprobacion de integridad referencial. Hace mucho el cambio de collar.
#31 creo que es más una cuestión de con que entorno el DBA esté cómodo... no conozco ninguna situación que no se pueda resolver con MySQL y si te pueda con PostreSQL.
Escalabilidad... he gestionado una base de datos con mas de 300 servidores en MySQL, no se que problema le ves.
Manejo de grandes bbdd... ver el punto anterior.
Comprobación de integridad referencial... en bases de datos lo suficientemente grandes, ese paso se realiza fuera del motor de bbdd, por que la integridad referencial es lo que hace que el rendimiento caiga drasticamente.
Ojo, que no digo que postgre sea malo, que me gusta, y seguro que es capaz de aguantar la misma chicha... y con toda la movida de la compra de Sun por parte de Oracle, quizá hasta sea la mejor solución, pero no tengo yo clara tu argumentación de que es mejor...
#32 puedes profundizar en lo de "en bases de datos lo suficientemente grandes, ese paso se realiza fuera del motor de bbdd"?
#33 Por supuesto...
Los sistemas de bbdd relacionales, por definicion, son lentos, y parte de la culpa de su lentitud, es la integridad referencial, que hace que, cuando quieras hacer una operacion de escritura, el motor tenga que pensarselo bien antes de dejarte realizar esa operacion. Lo que para ti es un simple DELETE manolito FROM users, hace sudar a la base de datos cuando manolito estaba referenciado en 20 tablas y unos cuantos cientos de miles de registros.
Ademas, son operaciones bloqueantes, por lo que si otra conexion esta haciendo un SELECT sobre una de las tablas que esta jodida buscando las referencias a manolito, pues ese SELECT se queda esperando.
Como lo solucionas... no usando integridad referencial... es decir, que el control sobre la integridad de los datos este en tu codigo, y no en la bbdd... porque tu codigo es una cosa que puedes escalar a placer (siempre que lo escribas teniendo en cuenta ciertas caracteristicas), y porque cuanto menos enlazadas esten las tablas en una bbdd, mas facil sera separarlas en caso de necesidad y tendras mayor granularidad sobre los accesos desde los frontales.
Conclusion, si la solucion es no usar la integridad referencial... para que quieres una base de datos relacional?? si la relacion entre unos datos y otros, esta controlada fuera del motor... pues un almacen clave = valor (mongo, cassandra, etc...) es mucho mas escalable y flexible, y curiosamente, es lo que se esta montando en cualquier entorno "gordo". Exceptuando probablemente los clasicos proyectos tan de moda entre las consultoras de Spring + Hibernate + JBoss + PostreSQL que son un desproposito si vas a tener mas de 10 personas visitando tu web/aplicacion.
#33 ORM FTW para esos casos xD
Tienes la logica de referencia en la capa de integración y no en la BBDD directamente (es un resumen de #34)
Basicamente se podria decir que es de la manera que se consigue en nosql integridad y demás polladas.
Thx por las respuestas.
#38 Es que en el momento que tienes los datos separados (con sharding por ejemplo) si haces un left join entre tablas que estén en diferentes máquinas, date por muerto xD
