none
pegunta sobre programacion y base de datos RRS feed

  • Pregunta

  • Saludos 

    muchachos que hay de cierto que todo lo relacionado a una aplicacion debe ejecutarse desde la misma base de datos ejemplos insert, update, consultas etc.

    que desde la  aplicacion no debo hacer eso me dicen que debe hacer store procedure

    me pueden decir con relacion a eso.

    jueves, 28 de junio de 2018 14:40

Respuestas

  • Desde mi punto de vista en en mi caso particular prefiero los Store procedures, ya que creo que se debe aprovechar los recursos y poder de procesamiento de la base de datos.

    Carlos Aldi

    • Marcado como respuesta agustin173 miércoles, 11 de julio de 2018 14:22
    jueves, 28 de junio de 2018 15:23
  • Buen día, antes que nada espero te encuentres bien

    Por lo que he tenido de experiencia, te puedo comentar que veo que depende de varios factores que mi caso en su momento fueron: tiempo de implementación, mantenimiento, infraestructura, dominio de la tecnología, entre otros más; dependiendo del proyecto a veces se le daba más peso a uno u otro, y con base a lo que preguntas y los factores que cito puedo comentar:

    • Tiempo de implementación: puedes tener dos opciones,
      • Utilizar algún ORM (como Entity Framework en .Net o Net Core) que te puede ayudar a realizar las operaciones CRUD de base de datos y en la mayoría de los casos sin definir Store Procedures además de la posibilidad de tener un control sobre los cambios en base de datos (tablas, campos nuevos) con Migraciones. Normalmente las operaciones CRUD con este tipo de herramientas son más rápido de implementar ya que usualmente  codificas directamente en el lenguaje de tu proyecto”, por ejemplo en C#, y utilizas las herramientas que te brinde el ORM para hacer operaciones CRUD. Aunque utilizar un ORM no te limita poder utilizar también StoreProcedures en tu proyecto
      • Utilizar librerías para acceso a base de datos directamente, por ejemplo ODBC, SqlClient, JDBC. El tiempo de implementación puede ser un poquito mayor, ya que, como recomendación, se crean StoreProcedures (Codificas en SQL) para ser invocados más tarde desde la aplicación (codificas en otro lenguaje: C#, Java, etc). Implica que tendrás qué codificar en ambos lados, porque de lado de la aplicación necesitarás parametrizar el Store, recorrer u obtener los resultados de un Data Reader o Dataset.
    • Mantenimiento: El mantenimiento de código, si lo manejas en la base de datos puede ser beneficioso si cambia la aplicación, ya que modificarías en menor grado las operaciones ya establecidas en base de datos (los StoreProcedures) o bien si lo único que tiene que cambiar es el flujo del proceso de los datos, sólo modificarías tus StoreProcedures “sin necesidad” de modificar la aplicación.
    • Infraestructura: Puede ser un factor si por ejemplo tu aplicación correrá en la nube o en un servidor de tu cliente (On Premise).
    • Dominio de la tecnología: Utilizar operaciones de lado de servidor de Base de Datos o servidor de Aplicación puede resultar mejor uno que el otro dependiendo del grado de conocimiento y gusto que adquieras para darle más velocidad y exactitud a tu proyecto.

    Mi conclusión, utilizo uno u otro dependiendo del proyecto y buenas prácticas  y políticas de mi organización. La experiencia te va a indicar en qué momento te será mejor una u otra, dependiendo de los factores (como los que cité anteriormente)  u otros factores que aparezcan. Estaré atento a tus comentarios y a los de los demás para conocer más experiencias

    Un cordial saludo


    ING.ARGAMA

    • Propuesto como respuesta Javi Fernández F jueves, 28 de junio de 2018 17:52
    • Marcado como respuesta agustin173 miércoles, 11 de julio de 2018 14:21
    jueves, 28 de junio de 2018 16:14
  • Hola:

    Coincido con lo que te ha indicado ING.ARGAMA.
    Personalmente me gustan los procedimientos almacenados, porque considero que la base de datos, es quien debe de poseer la capa más importante de tratamiento de los datos, dispone de todas las herramientas específicas para ello. Y casi siempre con Procedimientos, porque son más rápidos en comparación.

    Pero también utilizo, entity framework, porque, lo hace muy bien, y algo de ADO.NET....

    Cuando dispones de varias tecnologías, porque utilizar una sola. Utiliza, la que más te conviene, en función de tu conocimiento, y de a cual le puedes sacar mejor partido, para tu objetivo.

    Es posible, que si hago una consulta en procedimiento almacenado que calcula lo incalculable, pero la planteo mal, o no soy capaz de utilizar las herramientas de las que me dota el sql, sea una muy mala decisión, por contra una consulta normal, pero bien utilizada, si la resuelvo correctamente y una vez que la tengo en mi ASP, la resuelvo con LINQ, o con C#, o con cualquier otra tecnología, sea una buena decisión.

    A veces, tener una arquitectura perfecta, a la cual no sabemos sacarle partido, hace un mal producto.

    Un saludo

    • Marcado como respuesta agustin173 miércoles, 11 de julio de 2018 14:21
    jueves, 28 de junio de 2018 18:01
  • Gracias a todos por su respuesta me quedo claro
    • Marcado como respuesta agustin173 miércoles, 11 de julio de 2018 14:21
    miércoles, 11 de julio de 2018 14:21

Todas las respuestas

  • Desde mi punto de vista en en mi caso particular prefiero los Store procedures, ya que creo que se debe aprovechar los recursos y poder de procesamiento de la base de datos.

    Carlos Aldi

    • Marcado como respuesta agustin173 miércoles, 11 de julio de 2018 14:22
    jueves, 28 de junio de 2018 15:23
  • Buen día, antes que nada espero te encuentres bien

    Por lo que he tenido de experiencia, te puedo comentar que veo que depende de varios factores que mi caso en su momento fueron: tiempo de implementación, mantenimiento, infraestructura, dominio de la tecnología, entre otros más; dependiendo del proyecto a veces se le daba más peso a uno u otro, y con base a lo que preguntas y los factores que cito puedo comentar:

    • Tiempo de implementación: puedes tener dos opciones,
      • Utilizar algún ORM (como Entity Framework en .Net o Net Core) que te puede ayudar a realizar las operaciones CRUD de base de datos y en la mayoría de los casos sin definir Store Procedures además de la posibilidad de tener un control sobre los cambios en base de datos (tablas, campos nuevos) con Migraciones. Normalmente las operaciones CRUD con este tipo de herramientas son más rápido de implementar ya que usualmente  codificas directamente en el lenguaje de tu proyecto”, por ejemplo en C#, y utilizas las herramientas que te brinde el ORM para hacer operaciones CRUD. Aunque utilizar un ORM no te limita poder utilizar también StoreProcedures en tu proyecto
      • Utilizar librerías para acceso a base de datos directamente, por ejemplo ODBC, SqlClient, JDBC. El tiempo de implementación puede ser un poquito mayor, ya que, como recomendación, se crean StoreProcedures (Codificas en SQL) para ser invocados más tarde desde la aplicación (codificas en otro lenguaje: C#, Java, etc). Implica que tendrás qué codificar en ambos lados, porque de lado de la aplicación necesitarás parametrizar el Store, recorrer u obtener los resultados de un Data Reader o Dataset.
    • Mantenimiento: El mantenimiento de código, si lo manejas en la base de datos puede ser beneficioso si cambia la aplicación, ya que modificarías en menor grado las operaciones ya establecidas en base de datos (los StoreProcedures) o bien si lo único que tiene que cambiar es el flujo del proceso de los datos, sólo modificarías tus StoreProcedures “sin necesidad” de modificar la aplicación.
    • Infraestructura: Puede ser un factor si por ejemplo tu aplicación correrá en la nube o en un servidor de tu cliente (On Premise).
    • Dominio de la tecnología: Utilizar operaciones de lado de servidor de Base de Datos o servidor de Aplicación puede resultar mejor uno que el otro dependiendo del grado de conocimiento y gusto que adquieras para darle más velocidad y exactitud a tu proyecto.

    Mi conclusión, utilizo uno u otro dependiendo del proyecto y buenas prácticas  y políticas de mi organización. La experiencia te va a indicar en qué momento te será mejor una u otra, dependiendo de los factores (como los que cité anteriormente)  u otros factores que aparezcan. Estaré atento a tus comentarios y a los de los demás para conocer más experiencias

    Un cordial saludo


    ING.ARGAMA

    • Propuesto como respuesta Javi Fernández F jueves, 28 de junio de 2018 17:52
    • Marcado como respuesta agustin173 miércoles, 11 de julio de 2018 14:21
    jueves, 28 de junio de 2018 16:14
  • Hola:

    Coincido con lo que te ha indicado ING.ARGAMA.
    Personalmente me gustan los procedimientos almacenados, porque considero que la base de datos, es quien debe de poseer la capa más importante de tratamiento de los datos, dispone de todas las herramientas específicas para ello. Y casi siempre con Procedimientos, porque son más rápidos en comparación.

    Pero también utilizo, entity framework, porque, lo hace muy bien, y algo de ADO.NET....

    Cuando dispones de varias tecnologías, porque utilizar una sola. Utiliza, la que más te conviene, en función de tu conocimiento, y de a cual le puedes sacar mejor partido, para tu objetivo.

    Es posible, que si hago una consulta en procedimiento almacenado que calcula lo incalculable, pero la planteo mal, o no soy capaz de utilizar las herramientas de las que me dota el sql, sea una muy mala decisión, por contra una consulta normal, pero bien utilizada, si la resuelvo correctamente y una vez que la tengo en mi ASP, la resuelvo con LINQ, o con C#, o con cualquier otra tecnología, sea una buena decisión.

    A veces, tener una arquitectura perfecta, a la cual no sabemos sacarle partido, hace un mal producto.

    Un saludo

    • Marcado como respuesta agustin173 miércoles, 11 de julio de 2018 14:21
    jueves, 28 de junio de 2018 18:01
  • Creo que la pregunta es un poco simplista y ha orientado las respuestas hacia un subconjunto de razones que se orientan en el almacén, administración y transmisión de datos.  Tal vez la pregunta es correcta porque tal vez Agustín (quien pregunta) está realmente interesado en este aspecto específico únicamente; sin embargo yo sospecho que lo que hay leído o escuchado es acerca de un tema más general.

    Creo que la raíz de todo son las alternativas de "thin client" y "thick client".  Uno normalmente prefiere "thin client" que está acorde a la sugerencia que él muestra, que dice que uno debe relegar la carga al servidor.

    Pero la razón principal de hacer thin clients no es esa:  Es centralizar la lógica del sistema en las capas más próximas a los datos.  ¿De qué sirve tener, por ejemplo, 10 chequeos de seguridad y de integridad de los datos que digitan a través de un cliente Windows Forms (por ejemplo), si al final un DBA puede venir a insertar lo que se le venga en gana directamente en la base de datos?  ¿Y si alguien desarrolla una aplicación nueva que puede acceder a la base de datos?  Todos los chequeos, funciones e implementaciones en el cliente Windows Forms "oficial" serán simplemente eliminados de raíz.  Y no hablo de una aplicación furtiva.  Puede ser una aplicación legítima contratada por la compañía.  El punto es:  Cuanto más cerca del núcleo del sistema se encuentre todo, más difícil es de corromper.

    Por ejemplo, SQL Server:  ¿Accedemos datos vía un servicio MSSQLSERVER, o usamos System.IO.File para leer el archivo correspondiente?  Alguien por ahí, algún crack de programación podría aventurarse a leer el archivo, pero entonces habrá eliminado años y años de desarrollo de funciones, corrección de errores y refinamientos que existen en MSSQLSERVER.

    Si la fachada cambia, que sea difícil corromper el sistema.


    Jose R. MCP
    My GIT Repositories | Mis Repositorios GIT

    viernes, 29 de junio de 2018 4:08
    Moderador
  • Gracias a todos por su respuesta me quedo claro
    • Marcado como respuesta agustin173 miércoles, 11 de julio de 2018 14:21
    miércoles, 11 de julio de 2018 14:21