¿Por qué la mayoría de la gente dice que los servicios de datos y la base de datos son las partes más importantes de un sistema?

Question

¿Por qué la mayoría de la gente dice que los servicios de datos y la base de datos son las partes más importantes de un sistema?

Por lo que he visto, es el desarrollo del front-end: GUI, WEBUI, XAML que es el más importante. Ciertamente más importante que los niveles intermedios y de base de datos.

No creo que sea un gran problema construir la base de datos de una aplicación. Después de todo, el esquema de datos proviene del análisis de negocios y hay muy poco trabajo "creativo" por parte del desarrollador de la base de datos. Lo mismo es cierto para el lado de la lógica de negocios (nivel medio). Además, J2EE y .NET Enterprise Framework ayudan a desarrollar la lógica empresarial.

Entonces, ¿qué hace el desarrollador de la base de datos que es tan importante? ¿Por qué incluso necesitamos un desarrollador de base de datos independiente? ¿Por qué la mayoría de las empresas todavía pagan un salario más alto a los desarrolladores de middle/backend en lugar de a los desarrolladores de front-end?

Creo que los desarrolladores que construyen la IU (en Java o C#) deben tener conocimiento de la base de datos. Esto les permitiría construir toda la aplicación. En mi opinión, es imposible permitir que una persona con conocimiento que no sea base de datos desarrolle la aplicación de todos modos.

Háganme saber de qué me falta aquí.

Muchas gracias.

Answer 1

El front-end suele ser mucho más fácil de cambiar, mientras que el backend necesita más requisitos y fases de diseño. Si hay un cambio en el backend, entonces el front-end muy probablemente necesite cambiar, por lo tanto, las solicitudes de cambio relacionadas con los servicios de back-end (db, etc.) a menudo generarán muchos cambios en el medio y en el frente. Un cambio en el front end generalmente no afecta al back-end.

El problema de DBA realmente depende del tamaño de su proyecto. Si está hablando de proyectos con algunas tablas simples y algunos miles de registros, entonces probablemente tenga razón. Un DBA real probablemente consideraría que, por debajo de su/su valor para trabajar en ese proyecto de todos modos. Un DBA real es más como un administrador de sistemas que se especializa en optimizaciones de DBMS. Casi cualquier programador puede construir tablas, relaciones, vistas, procesos almacenados, etc. Y especialmente con los ORM fáciles de usar, muchas de las cosas que solían hacer los DBA no son realmente necesarias. Sin embargo, un DBA es crucial cuando se trabaja en proyectos grandes y sistemas de bases de datos grandes para optimizaciones de DBMS, configuración de sistema, configuración de conmutación por error, etc.

Su pregunta original no habla sobre el alcance del proyecto y creo que es donde está confundido o no ve la importancia de un DBA real (no debe confundirse con alguien que conoce un poco de SQL o ingresa datos y se llama DBA).

Answer 2

creo que el lado del extremo frontal: interfaz gráfica de usuario, webUI, XAML es más importante que nivel medio y de nivel de base de datos.

Eso es como decir que el color de un automóvil es más importante que el motor y los neumáticos.

Probablemente no sea un gran problema crear una base de datos. Sin embargo, es muy importante construir uno correctamente, optimizar uno existente y mantener un almacén de datos bien diseñado. IMO, es por eso que los chicos de la base de datos/almacén de datos reciben grandes cantidades de dinero.

Answer 3

Entre otras razones: con un nivel medio sólido, puede cambiar de una GUI a otra en función de los requisitos. (Por ejemplo, desde pre web2.0 a diseño web2.0) Por lo tanto, se necesita mucha más planificación para middle y niveles de backend en comparación con un frontend posiblemente intercambiable.

Answer 4

Todo es importante.

Answer 5

es imposible dejar que una persona que no conozca la base de datos desarrolle ninguna aplicación.

No si oculta las tablas de la base de datos con procedimientos almacenados envueltos en servicios web.

El front-end es simplemente una máscara sobre la aplicación real.

El nivel medio de negocios es el más difícil de programar en mi humilde opinión, ya que los empresarios rara vez saben cuáles son sus requisitos, a pesar de pensar que lo hacen. Ellos cambian de opinión regularmente. Las fundas Edge arruinan un diseño agradable y pueden ser muy difíciles de implementar.

No importa qué tan bueno sea su desarrollador de GUI si está escribiendo una interfaz en un nivel de negocios mal escrito. Y no se puede escribir un buen nivel de negocios en una base de datos mal diseñada.

Al final, es mucho más simple reescribir una GUI que cambiar la capa de la base de datos o el nivel medio, ya que un cambio en cualquiera de estos afecta a todos los niveles subsiguientes del programa.

Answer 6

Para una aplicación pequeña que juntas, la base de datos no parece tan importante, pero deja que esa aplicación crezca y evolucione con el tiempo y te encontrarás rápidamente con trampas debido a un diseño deficiente.

La capa de la base de datos y la capa intermedia son las claves para la longevidad y el mantenimiento de su aplicación.

Answer 7

La lógica de los negocios siempre es simple con ayuda de J2EE o DotNET enterprise framework.

Claro, la codificación de la lógica de negocios tiende a ser simple ... si no tiene que preocuparse por excepciones, manejo de errores, de hecho obtener los requisitos correctos del negocio, etc. Agregue la capacidad (necesaria ahora más que nunca) para una sola aplicación que admita múltiples front-ends (web, escritorio, móvil) y, de repente, la lógica empresarial "simple" se convierta en un punto crítico.

Answer 8

Algunos de los trabajos más desafiantes que he hecho como programador son las interfaces de usuario (xhtml, xaml, servlets, mvc, asp.net, etc.). Dicho eso, creo que te encuentras con dos problemas diferentes. En el lado de la base de datos, como dijo Mathew, un DBA verdadero podrá optimizar una base de datos grande (millones de registros) de forma tal que un desarrollador regular no sabrá cómo hacerlo. En el nivel intermedio, creo que la razón por la que la interfaz de usuario suele ser tan compleja es porque a menudo el desarrollador no construye realmente un verdadero nivel lógico intermedio/comercial. Entonces terminan poniendo toda la lógica en la aplicación en la interfaz de usuario, lo cual es incorrecto. Es RARO encontrar buenos desarrolladores que saben cómo construir una capa empresarial sólida y orientada a objetos que conozca el diseño impulsado por dominio y los patrones de diseño de OO. Cree un conjunto de clases con solo getters/setters que coincidan con sus objetos de base de datos NO es un diseño orientado a objetos. Por lo tanto, valen más.

Aparte de eso, estoy de acuerdo en que, aún así, el trabajo de IU es una programación muy desafiante y debe considerarse más importante de lo que es actualmente.

Answer 9

Es imposible responder a su pregunta.

Se basa en la premisa de que todos piensan que la base de datos es lo más importante en todos los sistemas, lo que es falso, obviamente, no todas las personas piensan eso, muchos sistemas no usan bases de datos y mucha gente con experiencia acepta que las partes más importantes de diferentes sistemas varían de un sistema a otro.

De hecho, según la definición de un sistema, ¡cada parte tiene que ser importante! Es posible que algunos subsistemas sean más caros que otros, algunos más tolerantes a los fallos que otros, algunos reemplazables de manera modular y otros no, pero todos son PARTE de un SISTEMA y, por lo tanto, SON importantes. La idea de que uno es más importante es difícil de cuantificar. Es concebible que algunas partes sean opcionales (como la decoración "no funcional") y, por lo tanto, podrían no ser consideradas parte del sistema. Sin embargo, en la visión más amplia del sistema, los usuarios participan y su interacción eficiente y alegre con el sistema es vital para garantizar su éxito.

Para usar una analogía ya publicada aquí, la pintura en un automóvil podría no ser tan importante como el motor, pero ¿alguien vendería un automóvil sin pintar? - no es probable (a menos que esa fuera la definición del producto, como muebles sin terminar).

De la misma manera que un motor es más caro que un trabajo de pintura, esperaría que paguemos más para diseñar motores que para seleccionar colores de pintura.

Hay un espectro de especialidades y complejidades en todos los sistemas.

Answer 10

No significa que todos puedan codificar bien en VC++, aunque tengan conocimientos en C++.

En el mundo técnico actual, cada desarrollador tiene conocimientos básicos sobre la mayoría de las últimas tecnologías. No significa que estén listos para diseñar un sistema con todas las tecnologías.

Todo viene con experiencia y especialización. Recuerde que pagaron bien por hacer DBA, sin hacer el diseño de UI.

No significa que los desarrolladores de IU no pueden diseñar una base de datos. También puede convertirse en un buen diseñador de DB, si tiene suficiente experiencia con el diseño de una base de datos.