web-applications - respaldar - copia de seguridad del sitio moodle
¿Alguien puede pensar en algunas buenas razones*no*para usar un DBMS orientado a objetos para respaldar un sitio web? (12)
Esto es un poco exagerado, pero para parafrasear una publicación de Joel, planifique el éxito. ¿Qué pasa si tu aplicación se vuelve realmente popular?
Por ejemplo, ¿qué sucede si aloja su aplicación en su propia máquina, pero decide ir a un sitio de alojamiento formal o incluso a una granja de servidores? ¿Cuáles son las posibilidades de que admitan un OODB frente a MySQL?
Supongamos que está codificando algún tipo de aplicación web. Algo donde las personas pueden contribuir con contenido, por ejemplo, un sitio simple para compartir fotos.
¿Cuántas buenas razones puedes pensar para no ir con una base de datos orientada a objetos (por ejemplo, db4o)?
Necesidad de velocidad cuando todo lo que tienes es una bicicleta de pedal. Los escenarios incluyen la captura de datos (por ejemplo, el registro) donde, después del evento, los datos capturados a menudo se procesan en una etapa posterior y probablemente se dividan en sus constituyentes de objetos de todos modos.
No sé cuán grandes son sus planes, pero la disponibilidad de personas experimentadas y capacitadas para contratar (o simplemente para echar una mano) sería un factor en mi decisión, así como también un conocimiento generalmente amplio con respecto a todos los ins. y outs de la DB.
Oracle o MySQL tienen sus fallas, pero las probabilidades son que si tienes un problema, otras 100 personas hayan tenido el mismo problema y te puedan decir cómo resolverlo.
Otra buena razón es la longevidad relativa. db40 es un producto excelente para lo que hace, pero su base de usuarios es pequeña y no es probable que sobreviva algo como SQL Server.
Por supuesto, también solía decir que no había forma de que Java sobreviviera.
Solo recomendaría ir a OODBMS si el diseño de su aplicación está muy orientado a objetos, y la complejidad lo necesita. Un sitio para compartir fotos no suena como que es pesado en el lado OO, por lo que no veo el sentido de ir por db4o.
Sin embargo, si realmente solo quiere aprender los pormenores de utilizar un OODBMS en un proyecto de mascotas, está bien usar uno.
Tamaño de los datos (si estoy lidiando con millones y millones de filas, me quedo con lo que sé)
Informes (normalmente lo suficientemente difícil en bases de datos normalizadas, peor en bases de datos OO)
Disponibilidad de experiencia / experiencia (RDBMS claramente tiene más adeptos)
Grandes cantidades de ETL (la mayoría de las personas importa y exporta en archivos planos, a menos que obtenga / envíe XML, está hablando de tablas antiguas)
Ninguno de estos suena como obstáculos para su proyecto
Un OODBMS es mejor si solo necesita acceder a sus datos a través de sus objetos. Si su solución requiere rutas adicionales a sus datos (por ejemplo, consultas ad-hoc, informes, otras aplicaciones que necesitan acceso a datos pero no pueden hacer uso de sus objetos), entonces un sistema RDBMS tradicional es mejor.
Nota: OOBBMS ha mejorado mucho en esta área.
Para informar con db4o, consulte:
http://developer.db4o.com/Resources/view.aspx/Reference/Implementation_Strategies/Reporting/
Quizás ustedes también quieran consultar este artículo:
http://microsoft.apress.com/asptodayarchive/74063/using-an-object-oriented-d
"Uso de un OODB en un sitio web" por Jim Paterson
¡Mejor!
Para una aplicación compleja con necesidades de datos modestas, no puede vencer a GLASS (Gemstone, Seaside y Smalltalk). Informes es definitivamente algo que desea hacer OO en Smalltalk.
Mi opinión personal, donde hay datos ... hay informes.
Ningún OODB le dará a sus datos el modelo de almacenamiento apropiado para estar disponible para sus aplicaciones de informes.
Yo diría que si está considerando algo como db4o, no parece que tenga ejemplos empresariales de sitios web activos, y en su mayoría están en uso para aplicaciones integradas.
Ver mi otra publicación en esto. ( Ejemplos de sitios web que usan db4o )
Nada técnicamente en el camino aquí, solo parece una adopción. Sin embargo, para una mayor velocidad de desarrollo, mantenimiento y flexibilidad de diseño, los OODB son bastante imbatibles.
informes pesados, etc. se pueden hacer mediante la sincronización con un back-end relacional si es necesario, que sé que db4o admite