design - usar - tipos de procedimientos almacenados

diseñando un sistema de distintivos, ¿dónde disparar la lógica empresarial? En código o procedimientos almacenados? ¿o ambos? (7)

Concentraría toda la lógica de negocios en un único idioma separado lógicamente en espacios de nombres o paquetes. Todo el trabajo necesario para ser hecho por la interfaz web, por ejemplo, sería expuesto por el servidor que utiliza los servicios.

Si construyera un sistema de credenciales similar a cómo lo hace SO, ¿pondría la capa lógica / comercial en la base de datos directamente (a través del procedimiento almacenado, los trabajos sql programados) o la pondría en el lado del servidor?

Por lo que puedo pensar, tienes que:

listar insignias que pertenecen a la acción del usuario actual
comprobar si el usuario ya tiene una insignia o no
insertar insignia para el usuario

Opciones potenciales

lógica de negocios en la aplicación web que llama a procedimientos almacenados, etc.
procedimientos almacenados SOLAMENTE
trabajo de servidor sql que se ejecuta cada x minutos
servicio de Windows que se ejecuta cada x minutos

¿Se requeriría una combinación de estos? Creo que, dado que algunas insignias se basan en hitos para una determinada pregunta, ¿quizás un trabajo por lotes es mejor?

Actualizar

Un sistema en el que puedes modificar el sistema de insignias y luego volver a ejecutar toda la insignia de vinculación para todos sería incluso mejor. es decir, cambie la lógica de algunas insignias, ahora tiene que volver a aplicarla a todas las preguntas / respuestas / votos / etc.

problema interesante para resolver !!

Entonces, este es un debate SO clásico y un debate entre apasionados programadores. He hecho una pregunta similar pero más genérica al respecto ...

lógica empresarial en la capa de la base de datos

Para responder a la primera parte, encontré aquí una de las mejores explicaciones que he visto sobre la lógica empresarial en el código frente a la base de datos:

http://www.codeproject.com/KB/architecture/DudeWheresMyBusinessLogic.aspx

Continúa explicando por qué la lógica empresarial es mucho mejor y escalable. También estoy en esa mentalidad ... así que para responder a su pregunta, no mantendría la lógica de negocios en la base de datos o en los procesos almacenados, por la razón principal, entre muchas otras, de que los SP no están controlados por la versión, y es un dolor para la versión controlarlos. Sin mencionar que los IDE para SP son infinitamente más primitivos que los IDE para el código. Y sql / tsql y cosas así no estaban destinados a la estructura de código complejo, sino a la manipulación básica de datos, y como verá en el artículo, para una estructura de código muy básica porque previamente la arquitectura cliente-servidor era limitada.

Algunas excepciones de esta página:

En un sistema de servidor cliente hay dos niveles, lo que obliga a implementar al menos dos capas. En los primeros días, el servidor simplemente se veía como una base de datos remota y la división se veía como aplicación (cliente) y almacenamiento (servidor). Por lo general, toda la lógica comercial permanecía en el cliente, entremezclada con otras capas, como la interfaz de usuario.
No pasó mucho tiempo para darse cuenta de que el ancho de banda de la red podría reducirse y la lógica centralizarse para reducir las necesidades constantes de redespliegue del cliente al sacar gran parte de la lógica comercial del cliente. Como solo había dos capas, el único lugar para mover la lógica de negocios era el servidor. El servidor arquitectónicamente era un lugar adecuado en un sistema de servidor cliente, pero la base de datos como plataforma era una mala elección. Las bases de datos se diseñaron para el almacenamiento y la recuperación, y su extensibilidad se diseñó teniendo en cuenta dichas necesidades. Los lenguajes de procedimientos almacenados de la base de datos se diseñaron para la transformación de datos básicos para complementar lo que no se podía hacer en SQL. Los lenguajes de procedimientos almacenados se diseñaron para ejecutarse muy rápidamente y no para la lógica comercial compleja.
Pero fue la mejor de las dos opciones, por lo que la lógica comercial se trasladó a los procedimientos almacenados. De hecho, yo argumentaría que la lógica de negocios era con cuernos de zapato (aplastada, hecha para encajar) en procedimientos almacenados como una cuestión de pragmatismo. En un mundo de dos niveles, no fue perfecto, pero fue una mejora.

La capa empresarial debe contener todas las reglas comerciales.
Tal diseño tiene las siguientes ventajas: - Toda la lógica comercial existe en una sola ubicación y puede verificarse, depurarse y modificarse fácilmente. - Un verdadero lenguaje de desarrollo se puede usar para implementar reglas comerciales. Tal lenguaje es a la vez más flexible y más adecuado para tales reglas de negocio en lugar de SQL y procedimientos almacenados. - La base de datos se convierte en una capa de almacenamiento y puede centrarse en recuperar y almacenar datos de manera eficiente sin ninguna restricción relacionada con las implementaciones de la lógica de negocios o la capa de presentación.

Entonces, ahora, con respecto a la arquitectura, lo haría para que las credenciales de cada usuario se actualicen llamando a un proceso almacenado cuando la pregunta / respuesta relacionada o cualquier otra cosa se actualice. Usted pone esto en la lógica comercial de la pregunta o respuesta, ya que supongo que será diferente para diferentes tipos de artículos (cuando se modifiquen). Debido a que esta es una acción basada en eventos, la acción solo ocurrirá cuando ocurra el evento. Si tiene un servicio o tareas programadas, se ejecutará todo el tiempo, y aunque sea mínimo, acabará por atascarse en el sistema cuando tenga muchos usuarios.

Si no desea que los eventos de cada uno de los usuarios desencadenen controles y actualizaciones de gazilion, puede agruparlos en una tabla y tener un trabajo programado para actualizar las insignias.

Para permitir que el sistema actualice una base de usuarios completa en función de la nueva lógica de negocios, puede abarcar todas sus acciones en un trabajo de Windows o un trabajo de una sola vez, y que funcionaría mejor que tsql, en mi humilde opinión, y sería mucho más fácil de mantener. y flexible

Sin embargo, a veces puede ser beneficioso duplicar MUY poco de la lógica de negocios, para obtener algo de rendimiento. Pero como puede ver en el artículo, la capa empresarial en el código es mucho más escalable, por lo que puede ser un punto discutible.

Espero que esta sea información útil para usted, que decida qué necesita ...

Escribiría un procedimiento almacenado, ya que toda la información necesaria reside en la base de datos, por lo que este es el lugar más eficiente para acceder a esa información.

Una regla tica podría implementarse mediante una sola instrucción INSERT en esta línea:

IF eligible for <new badge> THEN INSERT INTO user_badges SELECT <new_badge> WHERE NOT EXISTS (SELECT NULL FROM user_badges WHERE badge = <new_badge>); END IF;

(¡Simplito un poco!)

Lo pondría en la capa de negocios, después de todo esto es lógica de negocios de la que estamos hablando. Los procedimientos almacenados pueden, por supuesto, usarse para extraer los datos apropiados, pero no soy partidario de implementar la lógica de decisión únicamente en la base de datos. Si no hay nada más solo porque cada vez es más difícil seguir lo que está sucediendo al volver a visitar el código más adelante.

Personalmente, dejo la base de datos para hacer el almacenamiento / recuperación de datos y tengo la lógica en una ''capa de negocios''.

Tras el éxito de , estoy bastante interesado en implementar un sistema de logros para uno de mis sitios también, así que he pensado un poco en esto.

Actualmente estoy tratando de evaluar el valor de tener una rutina liviana (en términos de potencia de procesamiento) que podría ejecutar en respuesta a acciones específicas del usuario (votos positivos, nuevas respuestas, etc.) que podrían mantener la mayoría de las insignias. hasta la fecha según va el sitio.

Esto sería respaldado por una rutina más pesada que podría volver a calcular cada insignia desde cero. Esto se puede ejecutar periódicamente desde un servicio (o al menos un servicio simulado ) para asegurarse de que no se haya omitido nada, pero también en respuesta a un cambio en las reglas de la insignia.

Supongo que una gran parte de la respuesta a esto va a depender de los datos sobre los que se basan los premios de la insignia. Las insignias de parecen basarse tanto en datos (respuestas, preguntas, votos, etc.) como en eventos (ediciones, reetiquetado, etc.). Entonces, el algoritmo de la insignia probablemente debe estar interrogando a algún tipo de registro de auditoría o registro de "acciones".

Recomiendo encarecidamente dejar las decisiones a la lógica empresarial, no a los procedimientos almacenados. Los procedimientos almacenados son para el procesamiento de datos (es decir, recopilación de datos, comprobación de estados y condiciones particulares, eliminación, actualización, agregación, etc.). No es un lugar de creación para la lógica condicional (toma de decisiones).

En cuanto a eventos, versículos de datos: todo en un sistema de mérito es (o al menos puede ser) basado en eventos.

datos (respuestas, preguntas, votos, etc.) y eventos (ediciones, reetiquetado, etc.)

... Todos estos son eventos: responder una pregunta, hacer una pregunta, emitir un voto, etc.

Puede usar procedimientos almacenados para obtener los datos que necesita para determinar si se ha obtenido una insignia, pero su código debería tomar la decisión, y si corresponde, asignar la insignia. Los algoritmos para esto serían tan variados como las insignias, tal vez. Sin embargo, aquí hay un poco de lógica que seguiría:

Clasifique todas las insignias según los tipos de eventos que involucren (por ejemplo, responder una pregunta, hacer una pregunta, hacer una edición, volver a etiquetar, votar, etc.)
Cuando ocurre un evento en particular, toma todas las insignias asociadas con ese evento (es decir, que se puede obtener al completar la tarea que desencadenó el evento)
Recorre cada insignia en esa categoría y ejecuta su método Badge.VerifyCriteria (UserID)
Si el usuario aún no tiene la insignia, haz la asignación de insignia

El método VerifyCriteria sería un buen ejemplo de un posible lugar para un procedimiento almacenado, especialmente si necesita un mayor rendimiento. Esto es tanto verificar la base de datos para un estado o condición particular, como lo es la lógica comercial. Algunas insignias pueden requerir un procesamiento que es difícil en un lenguaje de base de datos (por ejemplo, SQL), por lo que VerifyCriteria debe ser un método real en el objeto que llama a procedimientos almacenados y / o código según corresponda. Esto también mantiene su lógica comercial amigable con OO.

Si quiere volver a marcar completamente a todos en el sistema, ejecutaría trabajos por lotes en segundo plano, o si el procesamiento es lo suficientemente ligero, simplemente actualice al usuario la próxima vez que inicie sesión, o la próxima vez que sea usuario se accede a los datos (por ejemplo, cuando alguien intenta ver su perfil). Pero lo mantendría todo en la lógica de negocios aún.

Yo recomendaría poner toda la lógica de negocios en la capa de negocios. Lo recomiendo por algunas razones:

Mantenga la lógica comercial en un solo idioma / lugar
Escalabilidad: puede dividir datos, implementar diferentes mecanismos de almacenamiento en caché, etc.
Separación de inquietudes: deje que su BD haga lo que mejor hace ... almacena datos, deje que su lenguaje de programación tome decisiones sobre esos datos.