database-design - tutorial - the django project
¿Dónde comienzo a diseñar cuando uso el mapeo O/R? Objetos o tablas de base de datos? (8)
Estoy comenzando una nueva aplicación de base de datos y me pregunto si sería mejor comenzar el diseño en los objetos (con UML) y construir el esquema de la base de datos en consecuencia, o comenzar con el diseño de la base de datos (con ER) y crear los objetos en consecuencia.
¿Cuáles son los pros y los contras de cualquiera de los enfoques?
(No creo que importe, pero por las dudas: planeo usar Java e Hibernate)
Comenzar en el nivel de la base de datos definitivamente le permitirá crear una base de datos que sea manejada más fácilmente por una base de datos relacional regular. Entonces, si espera obtener cientos de miles o incluso millones de objetos, este es el enfoque que tomaría. Sin embargo, si no espera obtener esa cantidad de datos, o si el rendimiento es irrelevante, me inclinaría por el enfoque de objeto, ya que le permitirá modelar una solución que se ajuste más fluidamente a su aplicación real.
Cualquiera de los enfoques puede funcionar, y cada uno tiene sus pros y sus contras. El enfoque centrado en DB es ideal para muchas aplicaciones que comparten datos. El enfoque centrado en el objeto es ideal para poner en marcha una sola aplicación.
Si el DB no existe, consideraría crear la aplicación sin preocuparse por ello. Tal vez algo como db4objs le daría la persistencia de objeto que necesita mientras desarrolla su aplicación en algo útil. Más tarde, cuando las nuevas aplicaciones están diseñadas para compartir los datos, o la consulta ad hoc se vuelve importante, una asignación de base de datos relacional tiene más sentido. Quizás nunca necesites relacional. Constrúyalo cuando lo necesite.
Si el DB ya existe, o es un requisito para obtener sus datos allí, aún así trataría de diferir el trabajo relacional el mayor tiempo posible y conseguir que los objetos y el código funcionen. Pero cambiaría de opinión si me veía escribiendo código complejo que SQL podría hacer.
Depende de dónde desee el mejor rendimiento. Si espera que la base de datos sea su cuello de botella, entonces comience a diseñar allí para que pueda ajustarla para el rendimiento. Si solo está utilizando una base de datos para guardar el estado de algunos objetos que deben ser efectivos en su aplicación, entonces diseñe según corresponda. El software de mapeo O / R no es tan confiable (aún, y no van a ponerse al día pronto) en la optimización del rendimiento como lo es un buen compilador. Igual hará un mejor trabajo de diseño para el rendimiento (aunque a un costo de desarrollo inicial más elevado).
Depende de dónde se encuentran sus puntos fuertes y hacia dónde desea ir.
Puede comenzar con objetos y hacer un buen trabajo, incluido un buen diseño de la tabla en su base de datos, si comienza en el lugar correcto.
Comience con un análisis orientado a objetos, en lugar de un diseño orientado a objetos. No puedo enfatizar lo suficiente la diferencia entre el análisis y el diseño. Las personas que escriben sobre el análisis orientado a objetos, algunos de los cuales usan UML como herramienta, intentan hacer esta distinción con claridad. El análisis se refiere al dominio del problema, mientras que el diseño pertenece al dominio de la solución. Estos pueden mezclarse fácilmente entre sí, ya sea que su enfoque esté orientado a objetos o no.
Si realiza un buen análisis OOA de los requisitos de su proyecto, probablemente pueda hacer un trabajo razonable de construir un modelo conceptual de datos en paralelo, y mantener esos dos sincronizados entre sí. Cuando construyes un modelo conceptual de datos, te sugiero que te mantengas en un modelo como el modelo ER.
Un modelo ER no le dirá cómo diseñar su base de datos. Ese es todo el punto. La forma en que separe las preocupaciones de análisis de las preocupaciones de diseño en el modelado de datos es hacer su análisis utilizando modelado de ER y su diseño utilizando modelado de datos relacionales, al menos al principio.
El mapeo entre OOA y ER es lo suficientemente simple para que pueda administrar los dos modelos en paralelo. Puede haber herramientas más nuevas que administren ambos tipos de modelos para usted. El mapeo entre ER y RDM es engañosamente simple. En el mapeo más simple, convierte cada entidad en una tabla con clave en la identidad de la entidad, y cada relación en una tabla separada con clave extranjera que se refiere a las entidades. Es posible y deseable reducir el número de tablas al enchufar algunas claves externas en tablas de entidades, pero eso es un detalle.
Desde OOA, procede a OOD para el diseño y OOP para la programación.
Desde ER para el modelado de datos conceptuales, proceda a RDM para el modelado de datos lógicos y a su dialecto DBMS específico de SQL para el modelado de datos físicos. Definitivamente hay herramientas para ayudarlo con esto, si su proyecto es demasiado grande para modelar en papel o pizarras blancas.
Periódicamente, construye lo que tiene, tal vez con stubs para la parte no construida, y concilia el diseño de su aplicación con el diseño de su base de datos. Si haces un buen trabajo, al final del día, deberías estar en muy buena forma.
Si está diseñando una base de datos y varias aplicaciones a la vez, las cosas se ponen realmente interesantes.
Depende de si su aplicación está diseñada para satisfacer las necesidades del usuario o para satisfacer las necesidades de los desarrolladores.
Comience con las historias de los usuarios y obtenga las clases de OOP directamente. Y tus usuarios te amarán
De lo contrario, terminará con una aplicación que convierte a los usuarios en empleados de entrada de datos. (Tendrás mucha compañía).
Eso depende. ¿Estás haciendo programación orientada a objetos o programación orientada a SQL?
La ventaja de comenzar con la base de datos es que tendrá en cuenta el rendimiento y sus DBA.
Las ventajas de comenzar con el lado de OOP es que tendrá un diseño de OO más puro, pero su ORM podría tener un rendimiento inferior.
Encuentro que los ORM de caja negra son demasiado limitantes, por lo que todos mis sistemas están codificados a mano o generados y modificados por código, por lo que mis bases de datos suelen ser bastante compactas Y mi modelo OO es puro. Creo firmemente que los humanos inteligentes son la solución al desajuste de la impedancia.
Si está escribiendo una aplicación OO, entonces creo que el diseño de los objetos primero es el lugar para comenzar. Prefiero crear un buen OO Design y luego intentar optimizar la base de datos en lugar de crear una base de datos y luego intentar ajustar los objetos a la base de datos.
Las herramientas ORM le dan la libertad de enfocar su atención en el diseño del objeto.
Sin embargo, no reemplaza el buen diseño de la base de datos. Aún debe vigilar la base de datos. Me parece que con una reflexión cuidadosa, las asignaciones de OR se pueden hacer para que la base de datos creada esté bastante optimizada. Siempre puede ver las consultas e intentar optimizarlas si encuentra que algunas consultas tienen un bajo rendimiento.
No debería tener que crear una aplicación que se ajuste a un modelo de base de datos, la base de datos debe diseñarse para admitir sus aplicaciones. Y las herramientas ORM le permiten crear bases de datos optimizadas y consultas.