database - software - ¿Cuál es más importante? Diseño de DB o codificación?

database diagram tool (30)

El modelo de dominio debe ser independiente de los detalles de implementación de persistencia (aunque la tecnología sí impone algunas limitaciones al modelo) -

Debes enfocarte en el modelo de dominio. Con una gran tecnología ORM como Hibernate / NHibernate la base de datos solo será un detalle de implementación.

Libros que deberías leer si estás haciendo desarrollo web .NET:

ASP.NET MVC Framework Preview (solo 100 páginas, y le ayudará a comenzar)
NHibernate en acción
Diseño y desarrollo impulsados por el dominio en la práctica (no lo lea, pero lo haré, y es gratis)
Refactorización: mejorar el diseño del código existente

¿Qué es más importante: el diseño de la base de datos? ¿O el diseño del código de la aplicación?

Hay mucha información sobre el código reutilizable (de Carl Franklin en dnrtv.com , CSLA.net , et al.), Pero no veo demasiada información sobre el diseño de la base de datos y su impacto en la vida de un aplicación (en particular, cómo las malas decisiones de diseño desde el principio afectan la aplicación más adelante en su ''vida'').

Ambos

Un código horrible puede arruinarse con un diseño db horrible y un diseño excelente de db puede arruinarse con un código horrible.

Ambos son importantes, pero el diseño deficiente en cualquiera de las actividades iniciales suele ser más difícil de corregir. Los cambios en las especificaciones funcionales, por ejemplo, generarán naturalmente mucho más trabajo que algunos cambios de verborragia en la interfaz.

Cualquier cambio significativo en la base de datos generalmente también requiere cambios de codificación, así que paso mucho más tiempo angustiado por las decisiones de diseño de la base de datos y las decisiones de codificación (aunque estoy seguro de que no soy el único que ha pasado una o dos horas intentando para encontrar el nombre perfecto para una clase).

Ambos son importantes, por supuesto, es una relación simbiótica.

Pero si su base de datos está conectada, ninguna cantidad de código bueno puede hacer que su aplicación brille.

Sin embargo, si su base de datos es realmente buena, un buen código puede hacerlo aún mejor (pero un código incorrecto puede arruinarla).

Ambos son solo parte de la implementación de aquello en lo que, por supuesto, pasas la mayor parte de tu tiempo inicial: requisitos y diseño.

Depende de lo que disfrute, por supuesto, pero el futuro está en abstraer la capa de datos, es decir, considerar el almacén de datos como un detalle de implementación en lugar del núcleo de la aplicación.

Escuchará el término "ignorancia de persistencia" en ciertos círculos. El objetivo es que el modelo de dominio (entidades comerciales) se diseñe sin saber cómo se almacenarán los datos. Detrás de escena, puede estar en SQL, AmazonDB o XML.

Si te gustan las cosas de DBA, ahí es donde deberías estar. Pero si desea ser más del lado de la aplicación, conozca los marcos ORM.

Depende de lo que es importante para su negocio. Lo ideal es que no cambie demasiado, pero si debe hacerlo, también debe hacerse esta pregunta:

¿Su aplicación está allí para manejar datos, o los datos trascienden su aplicación?

En otras palabras, si la parte del código de su aplicación estalló hoy, pero sus datos aún están allí, ¿qué tan malo sería un desastre? Si tu respuesta es:

Siempre puedo escribir el código para reemplazar la aplicación, pero sin los datos, estamos condenados.

Entonces es mejor que se asegure de que sus datos estén en buen estado, porque es probable que sobreviva a cualquier código que escriba hoy. Eso no quiere decir que no deba esforzarse mucho para escribir una base de código sólida, pero el código es transitorio en última instancia, mientras que sus datos no lo son. Si tiene un código incorrecto, puede volver a escribir, pero si tiene datos incorrectos, es probable que tenga implicaciones mucho más amplias.

Por otro lado, si los datos solo están realmente allí para asegurarse de que su código funciona bien, y el código en sí mismo es más importante (el inverso del escenario anterior), debe asegurarse de tener una buena base de código y revisar cualquier deficiencias en los datos más tarde.

EDITAR

En la mayoría de las aplicaciones empresariales, los datos son mucho más importantes. Trabajé en proyectos de conversión en el pasado donde el código ya había pasado su vida útil, pero la migración se retrasó durante tanto tiempo (a veces décadas) porque los datos eran tan malos que se requirió un esfuerzo significativo y muy discrecional para obtener los datos punto de salud donde podría ser migrado.

Depende de uno en el que tenga conocimiento sobre ambos ... y los requisitos del producto.

Olvídese de cualquier lado y su producto podría tener problemas.

Dicho esto, tiendo a seguir un estilo de codificación DDD, donde defino todo menos mi base de datos primero. Eso me da una mejor idea de qué datos deben almacenarse.

Luego, una vez que esté completo, puedo crear y ajustar mi base de datos a la suite.

Diseña si eres un DBM.

Codificando si eres un programador

Estos no son mutuamente excluyentes y ambos deben ser bien ejecutados.

En cierto sentido, no puede separar los dos: el diseño de DB es la codificación; simplemente no está codificando en un lenguaje de procedimiento.

Sin embargo, he trabajado con sistemas que tenían un software de procedimiento mal diseñado, y he trabajado con sistemas que tenían esquemas de bases de datos mal diseñados (¿esquemas?). En mi experiencia, arreglar los esquemas es mucho más difícil debido a problemas de actualización y compatibilidad. Puedo imaginar sistemas donde esto podría no haber sido el caso.

En general, la estructura de la base de datos es más importante, ya que proporciona el marco estructural en el que se desarrolla su código. En general (e YMMV bastante), la refacturación de su estructura de base de datos después de completar una fase de desarrollo es significativamente más difícil que simplemente refactorizar el código que depende de una base de datos estable. La razón es simple; la refacturación de su estructura de base de datos normalmente obliga a los cambios de código; el reverso rara vez es verdad.

Simplemente, su código depende de su base de datos más de lo que su base de datos depende de su código. (Si este no es el caso, es posible que deba reconsiderar su diseño).

Para abordar su edición; Creo que muchas personas que escriben / bloguean sobre este tipo de temas suelen tener una fuerte influencia del lado "codificador" de las cosas. Este tipo de personas tienden a considerar el diseño de bases de datos como algo trivial y menos interesante que la codificación de soluciones interesantes. Esencialmente, para alguien a quien le gusta resolver "problemas complicados" (que tiende a ser la gente que bloguea más), el lado de la codificación es más interesante que los problemas de diseño fundamentales. Y si bien los problemas fundamentales de diseño no son "sensuales", son extremadamente importantes (y el Diseño de la Base de Datos es un tema de diseño MUY fundamental).

En mi humilde opinión, el buen diseño de la base de datos es más importante que una buena codificación (una buena codificación también es importante, pero se puede comparar con el diseño de la base de datos).

Simplemente porque la base de datos almacenará sus valiosos datos.
Es posible que la mala codificación no afecte a la base de datos, pero afectará la escalabilidad, el rendimiento de toda la aplicación, etc. Durante un período de tiempo, esto puede solucionarse mediante refactorización (por supuesto, con algún costo).
Refactorizar una base de datos es mucho más costoso y difícil.
También normalmente tenemos múltiples aplicaciones diferentes que se ejecutan en la misma base de datos, por lo que es un factor común.

Eso depende de tu perspectiva. Si eres un DBA, entonces el DB, si eres un desarrollador que el código.

He visto a los desarrolladores abusar completamente de la base de datos con tablas de "bolsa" y he visto que los DBA crean un código de aplicación monstruoso que está bien si entiendes la estructura de la base de datos pero, en caso contrario, es opaca.

Ergo, ambos son críticamente importantes y si solo tienes experiencia en uno, debes tener a alguien con experiencia para que se mire al otro o mejore tu propio conjunto de habilidades donde falta.

Estoy de acuerdo en que ambos son críticos, pero existen técnicas sustanciales que puede usar en la vista, función, nivel de procedimiento almacenado para compensar fallas de esquema subyacentes bastante horrendas. Por otro lado, si su codificación es mala, además de corregirla, por supuesto, no hay mucho que pueda hacer a nivel de diseño para arreglar eso.

Ha sido mi experiencia (y he estado involucrado en la reparación de problemas de bases de datos durante aproximadamente 30 años y he tratado con cientos de bases de datos diferentes) que muchos de los problemas en el rendimiento de la base de datos provienen de los intentos inadecuados de reutilizar el código. Las funciones son mucho más lentas que el código en línea. Los cursores que reutilizan un proceso almacenado que inserta un registro a la vez son muy, muy, muy lejanos (años luz) más lentos que el código basado en conjunto. Reutilizar un programa que devuelve lo que necesita y otros diez campos es un desperdicio de recursos de servidor y red. Usar una vista existente que se une a diez tablas cuando solo necesita información de tres de ellas es un desperdicio de recursos del servidor. La reutilización de código en bases de datos no es tan buena como en otros lugares. Esto no quiere decir que el código no deba reutilizarse si es necesario. Solo que nunca debería tener prioridad sobre el rendimiento. Desafortunadamente, las bases de datos no están bien diseñadas para reutilizar el código. La mayoría de las bases de datos no están orientadas a objetos y el pensamiento orientado a objetos al diseñarlas o acceder a ellas a menudo dará como resultado un diseño deficiente.

Antes de que pueda siquiera pensar en la reutilización del código, debe tener un diseño de base de datos normalizado sólido como una roca. Debe pensar en cómo va a extraer e insertar datos en la base de datos. Debe pensar en qué tan bien funcionará una vez que haya muchos usuarios y registros, ya que el rediseño de una estructura de base de datos básica en este punto a menudo resulta demasiado costoso y lento. A menudo es mucho más fácil refactorizar el código de la aplicación que la estructura básica de la base de datos y, con demasiada frecuencia, no se lleva a cabo la refactorización de la base de datos. Si cambia la estructura de la tabla para pasar de una tabla desnormalizada a una estructura secundaria principal porque descubre que la estructura actual no satisface sus necesidades, entonces puede terminar cambiando cientos o incluso miles de consultas en esta tabla. Es por eso que es importante dedicar mucho tiempo al diseño de bases de datos, no tendrá la oportunidad de volver a visitarlo más tarde debido a restricciones de tiempo / dinero. Si considera la base de datos como la base de la casa y el código de la aplicación como la estructura, verá por qué esto es cierto. Es mucho más difícil cambiar la base con la estructura encima que mover las paredes internas. Las bases de datos y las aplicaciones que acceden a ellas son de la misma manera.

Habiendo trabajado antes con un espantoso diseño de base de datos, debo poner mi sombrero en el anillo de diseño de la base de datos (o modelo de datos / ORM).

Reúnase con algunas personas conocedoras de su empresa / cliente sobre el área problemática, y obtenga todos los datos requeridos en papel, agrúpelos por áreas lógicas, luego comenzará a formar un modelo de datos que podría convertir en Objetos, Esquemas de base de datos o un .xsd, etc. Cada elemento de datos tendrá un nombre, un tipo, tal vez la longitud máxima de las cadenas, o un conjunto o lista o mapa de ciertas capacidades mínimas o máximas.

Ya sea que usted diseñe la base de datos primero después de esto, o el modelo OO depende de usted, pero al menos se esforzó por obtener un modelo sano particionado por adelantado.

De hecho, en un diseño de MVC, clasificaría el modelo de datos de OO (clases en Java / C #) como el modelo y me vincularía intrínsecamente con el esquema de la base de datos (con transitorios y métodos de utilidad añadidos, por supuesto). Su controlador - la "codificación" en su pregunta - realmente debería implementar la lógica comercial usando el modelo representado por los objetos que extrae de la base de datos a través de un DAO / ORM.

Míralo de esta manera

Cambiar el código significa cambiar el código
Cambiar la base de datos probablemente lo forzará a cambiar el código también

Por lo tanto, es importante que la base de datos sea lo más estable posible lo antes posible.

Ninguno de los dos es importante, pero ...

El mal diseño de la base de datos puede hacer que escribir buenos programas sea imposible. Además, generalmente puede reescribir el código incorrecto, pero si tiene muchos datos en la base de datos, solo tiene que vivir con las malas decisiones tomadas en la fase de diseño.

No creo que puedas separar los dos de la manera que estás describiendo. Uno influirá invariablemente en el otro. Por ejemplo, un diseño de base de datos sólido que sea fácil de mantener y funcione bien significará menos cambios de código. Un código bien estructurado y una sólida comprensión de sus casos de uso conducirán a un esquema de base de datos limpio y mantenible.

Por mi dinero, gastaría más en una capa empresarial sólida y construiría mi base de datos para respaldarlo, pero ese es mi sesgo de conocimiento.

No intentaré duplicar muchos de los buenos comentarios hechos hasta ahora. Tampoco voy a pasar el tiempo identificando las declaraciones dudosas también hechas.

Pero agregaré los siguientes puntos.

Si es como la mayoría de las personas, se refiere a un RDBMS como base de datos en su pregunta. Un RDBMS es esencialmente un esclavo. Escucha en un puerto y está obligado a intentar dar servicio a todas las solicitudes que llegan a ese puerto. No tiene forma de saber cuáles de esas solicitudes son simplemente estúpidas o desacertadas. Por lo tanto, es fácil abusar del DB más perfectamente diseñado hasta el punto de bloquear el servidor. Esto implica que el código es más importante. Se puede encontrar a los DBA de todo el mundo sacándose el pelo en respuesta a algunas de las cosas más tontas que los desarrolladores de aplicaciones lanzan en los servidores que administran.

Entonces, el mejor consejo que puedo darte sobre el tema es asegurarte de que a la base de datos se accede mediante una API escrita por el mismo desarrollador que diseñó la base de datos. Haga que sea responsabilidad de un amigo (o un grupo que informe al mismo tipo) para garantizar que se tomen decisiones de diseño acertadas para ambos. Si eres ese tipo, entonces no escatimes en uno a expensas del otro. Diseña tu API para que se pueda realizar una refacturación de la base de datos de forma transparente a los clientes de la API.

No son mutuamente exclusivos. Ambos deben ser sólidos como una roca para tener la oportunidad de encontrar una solución sólida como una roca.

Parafraseando a Knuth

Es mucho más importante usar una estructura de datos eficiente. Una mala estructura ralentizará su aplicación independientemente de su algoritmo y una buena estructura puede incluso eliminar la necesidad de ciertos algoritmos.

Creo que esto se aplica igualmente a los DB. En última instancia, está construyendo una estructura de datos vinculada masivamente. Si no usa los métodos correctos, su aplicación será lenta, independientemente de la cantidad de engaños que ponga en ella.

Puedo ver que voy a estar nadando río arriba, pero estoy bastante predispuesto a que el software sea la respuesta a tu pregunta.

Si bien su software se puede adaptar a un esquema débil, su base de datos no puede ayudarlo mucho si su software no es funcional. He tenido un par de casos en los que he podido tomar una aplicación front-end popular y reconstruir totalmente la base de datos sin interrupciones graves, porque los usuarios no ven directamente la base de datos. (Lo cual no será cierto si el software es basura.)

Así que diría que primero preste atención a lo que está más cerca del usuario.

Respuesta corta: ambas. La cadena es tan fuerte como el eslabón más débil.

Si eres descuidado con cualquiera de ellos estás condenado.

Si no está seguro de sus habilidades en cualquier área, haga lo posible para separar las dos tanto como sea posible. El peor escenario es escribir un lío enredado que no se puede corregir o mantener fácilmente más tarde.

Tal vez, no tengo mucha experiencia en el diseño de bases de datos, pero mi sensación es: si sus clases de negocios están bien diseñadas, el único punto donde accede a la base de datos está en sus repositorios (DDD hablando).

Entonces, un cambio en la base de datos es solo un cambio en la implementación de su repositorio. Un mal diseño de la base de datos hará que su repositorio sea difícil de codificar, y su rendimiento sea lento, pero no afectará su capa de negocios (90% de su código).

Si intenta modificar su capa de negocios debido a su capa DAO, ¿por qué no modificar su capa de negocios debido a su capa de presentación? ¡y luego buena suerte para satisfacer todas las restricciones y buenas prácticas!

Creo que ambos son importantes, pero la codificación y el diseño de la base de datos no deberían estar en las mismas manos. Lo más importante para el desarrollador es aislarse del trabajo del diseñador de db. (Incluso si el diseñador de Db y el desarrollador son la misma persona, no debería tener que pensar en dos cosas al mismo tiempo)

Una base de datos es un artefacto de un programa de computadora que modela un proceso y sistema dados

Idealmente no debería ser una preocupación

La tecnología actual de persistencia de objetos aún no está allí, por lo que probablemente te preocupe por un tiempo.

La pregunta es: ¿para qué sirve la base de datos?

Si está allí para conservar los objetos en su modelo de procesos y sistemas, entonces no debería tener mucho que ver con eso

Si está ahí para arreglar agujeros en su modelo, pasará mucho tiempo en él

hemos reescrito el sitio web 3 veces en 4 años. la base de datos no ha cambiado. (bueno un poco)

Tu diseño de base de datos es lo más importante.

Soy un codificador, y prefiero el código, pero ... si arruinas el diseño de DB, tu código será una pesadilla. ¡Tu código no tendrá ninguna posibilidad!

Incluso cuando intente refactorizar el diseño de DB, tendrá tanto trabajo con el código, que arreglarlo será abrumador.

Esta no es una preferencia o incluso una cercana, se inclina mucho hacia el diseño de la base de datos que sea más importante.

EDITAR: incluso si tuvieras tablas de pares clave-valor donde todo se volcara, seguiría siendo un diseño de BD basado en los requisitos del negocio.