database design - tool - ¿Cuál es la mejor práctica para almacenar una "búsqueda guardada" en una base de datos?

google database design tool (8)

Estoy trabajando en una página de búsqueda que permite a los usuarios buscar casas en venta. Los criterios de búsqueda típicos incluyen precio / código postal / # dormitorios / etc.

Me gustaría permitir que el usuario guarde estos criterios en una base de datos y envíe correos electrónicos a nuevos hogares diariamente.

Yo podría:

1) Serialice un objeto "SavedSearch" en una cadena y guárdelo en la base de datos, luego deserialícelo según sea necesario.

2) Tener una lista de columnas en un tblSavedSearch correspondiente a los criterios de búsqueda - precio / zip / # dormitorios / etc.

Me preocupa que si elijo la opción 1, mis criterios de búsqueda guardados cambiarán y dejarán inválidos los objetos publicados en la base de datos, pero la opción 2 tampoco parece una solución óptima.

¿Cómo han resuelto otros este problema?

Puede guardar el SQL dinámico en la base de datos como una cadena de texto. Entonces no tendrá que hacer todas las maquinaciones de recreación de WHERE e IN y otro SQL de los pares clave-valor guardados.

Puede usar el SQL guardado y ejecutarlo cuando genere el correo electrónico.

Si el diseño de su base de datos no es lo suficientemente estable como para guardar información de consulta, es posible que deba diferir el diseño de búsqueda hasta que el diseño de la base de datos sea más maduro.

Si puedo sugerir, tengo una página html con resultados de búsqueda (si contiene un número moderado de registros). Y, almacene la ruta junto con los criterios de búsqueda en la base de datos.

Esto evitará consultar el DB.

Editar: supongo que los registros no cambiarán con tanta frecuencia. Si lo hace, es mejor almacenar los criterios de búsqueda en la base de datos y consultarlos cuando el usuario lo solicite.

Supongo que tendrá que volver a ejecutar la búsqueda diariamente para encontrar nuevas adiciones a los resultados. Tal vez sea posible asegurarse de que el formulario de búsqueda especifique un método get para que los criterios de búsqueda se anexen a la url como una cadena de consulta y luego guarden toda la cadena de consulta en la base de datos.

Entonces, si tiene un programa de búsqueda llamado search.action, solicitará la búsqueda de esta manera:

search.action?price=20000&rooms=3

Puede guardar el precio = 20000 & habitaciones = 3 parte en la base de datos. Para recuperar esta búsqueda, simplemente agregue la cadena de consulta en la url y solicite la página de búsqueda nuevamente.

La única advertencia es que a medida que cambia la acción de búsqueda, debe realizar ajustes predeterminados inteligentes para evitar romper búsquedas antiguas. Por ejemplo, supongamos que comienzas a buscar por color, ninguna de las búsquedas anteriores tendrá un criterio de color, por lo que tu acción de búsqueda tendrá que atender esto y asegurarte de que se use algo razonable como TODOS los colores.

Yo iría con el # 1. Si realmente está preocupado por el cambio de los criterios, puede almacenarlo con un atributo de "versión de búsqueda" y dar masajes a la representación serializada cuando sea necesario.

# 2 no se escalará a ningún tipo de utilidad. Por ejemplo, si quiere hacer algún tipo de agrupamiento booleano de criterios de búsqueda, su esquema DB se prenderá fuego y correrá gritando al bosque.

Generalmente resuelvo problemas de búsqueda sacando la indexación / búsqueda de la base de datos. Eso puede ser demasiado para lo que estás hablando, pero los RDBMS no son tan buenos para buscar.

usuarios de mesa

tabla Criterios (= la lista de criterios de búsqueda proporcionados)

tabla SavedSearch (detalle de los usuarios)

tabla SavedSearchCriteria, detalle de SavedSearch, Criterios de referencia, columna SearchValue contiene el valor ingresado por el usuario para cada uno de los criterios ingresados

Creo que ambos enfoques tienen sentido, y todo depende de los requisitos (actuales y prospectivos).

Por ejemplo, si el número de búsquedas es alto y si necesita analizarlas (por ejemplo, responder preguntas como "¿Con qué frecuencia busca la gente cada número de habitaciones?" ), Almacenar búsquedas y sus criterios en forma relacional (su opción # 2) sería más que apropiado.

Pero si no tiene ningún requisito inminente que dicte el uso de la opción n. ° 2, no hay nada de malo en serializar, en mi humilde opinión. Solo asegúrate de NO romper la compatibilidad con los datos existentes ya que la estructura de tus criterios de búsqueda cambia con el tiempo. (Por cierto, los problemas de compatibilidad con versiones anteriores no son específicos de la opción n. ° 1: pueden ocurrir incluso cuando se usa la opción n. ° 2). El punto clave es: siempre puede cambiar de la opción n. ° 1 a la opción n. ° 2 y posponer las modificaciones durante el tiempo que considere práctico.

También agregaría visibilidad de datos a la solución ... así como a Table Users - contiene a los usuarios Table Roles - contiene los roles en el db Table UserRoles - un usuario puede tener uno o más roles en una sesión Table MetaColumns - contiene la meta información para todas las columnas / vistas en el db Table ControllerMetaColumns - visibilidad por MetaColumns por UserRole, los usuarios siempre tendrían que acceder a los datos reales a través de este (INNER JOIN) Table TableViewToSearch - la tabla o vista para realizar la búsqueda en Table SavedSearch - Tiene los atributos ControllerMetaColumnsId, TableViewToSearchId, SavedSearchString - si la función no tiene acceso al atributo, se le dará un conjunto de resultados vacío

La mejor manera de lograr esto es almacenando sus criterios de búsqueda como XML. Esto le permitirá derivar sus criterios de búsqueda fácilmente y proporcionar la posibilidad de que el usuario lo modifique si es necesario.

XML debe ser la solución más escalable y evitaré pasar parámetros de URL a la acción. Puede ser una solución simple pero tendrá los siguientes problemas.

Si el usuario quiere editar un nuevo criterio de búsqueda, entonces tenemos que hacer una manipulación de cadena a gran escala.
El almacenamiento de criterios de búsqueda complejos será un problema. ¿Qué sucede si quiero guardar un complejo y / o condición? (En XML, ya que es jerárquico, podría almacenar toda la información que necesito).
La solución podría ser escalable y también desinfectará su aplicación de los ataques de inyección Sql.
Dado que XML es una tecnología madura, puede usarlo incluso para realizar la validación antes de pasarla al back-end.