Voy a probar esto de una forma cruda de prueba de concepto, y luego me puede decir qué necesitamos hacer al respecto.
De acuerdo, debes averiguar qué quieres probar y una estructura que te permita hacerlo.
Comenzaría con la tabla, y voy a juntar esto en MySQL solo porque está disponible y es fácil de traducir.
- ¿Cuál es la diferencia entre un error de caché y un acierto de caché?
- ¿Cuál es la mejor manera de dividir las responsabilidades entre los equipos front-end y back-end para el desarrollo web?
- ¿Qué hace Cloud9 (IDE web) mejor que sus competidores?
- Cómo hacer que mi blog sea visible en los resultados de búsqueda de Google
- Como usuarios de comercio electrónico, ¿siempre tenemos que crear una cuenta de cliente separada para cada tienda? ¿Por qué los grandes jugadores como Google o PayPal aún no han creado una solución de inicio de sesión único o tal solución ya existe?
CREAR CUPÓN DE MESA (
COUPON_ID int auto_increment,
CUPÓN PARA CLIENTES varchar (15),
CUPÓN DE ANTECEDENTES varchar (255),
ACTIVEDATE datetime default NULL,
EXPIREDATE datetime default NULL,
TÉRMINOS varchar (255),
CLAVE PRIMARIA (ID DE CUPÓN));
Ahora necesitamos una tabla de condiciones
CREAR CONDICIONES DE CUPÓN DE MESA (
COUPONCONDITION_ID int auto_increment,
Texto RULE2BEMET,
Texto RESPONSEIFRULENOTMET,
CLAVE PRIMARIA (COUPONCONDITION_ID));
Ahora necesitamos hablar sobre la implementación.
Muy bien, los 255 caracteres de mi backend facingcoupon no serían más que 1 para verdadero y 0 para falso. Usaría herramientas de manipulación de cadenas para recuperar el CouponCondition_ID anterior en función de la posición.
RULE2BEMET sería una restricción de hibernación, un HQL o incluso una regla SQL sin procesar o un procedimiento Function / Store que ejecutaría para recuperar verdadero o falso. Mi consulta SQL final sería determinar un caso en el que todas mis reglas sean verdaderas, el cupón se pueda aplicar, cuando cualquiera de las reglas sea falsa, el cupón no se pueda cumplir, y si no se puede cumplir, yo agregue el texto del texto RESPONSIBLEIFRULENOTMET a una lista de por qué no se puede usar ese código de cupón.
Al abstraer el cupón de back-end y el cupón de front-end, ofuscaría toda la funcionalidad del usuario. Los TÉRMINOS serían lo que hace el cupón, a menos que quiera usar otra cosa para manejar la regla. Creo que es un usuario existente la primera COUPONCONDITION, y mantendría mis reglas lo suficientemente genéricas como para no quedarme sin caracteres demasiado rápido.
Sin escribir el SQL para hacer las funciones que analizarán todas sus reglas que lo acercarán bastante, creo.
