buscador facetado dedicado para hacer frente a las taxonomías dinámicas - ayuda acaba con el rendimiento o también flexibilidad?

Question

He estado pensando un rato sobre el modelado de sitio de comercio electrónico típico con la taxonomía ebay-como y atributos depende de una determinada categoría de producto.

En primer intento fue elegir entre EAV y la Tabla de modelado por la herencia de clase db. He elegido este último debido a la actuación, pero lo que significaba era la creación de la mesa dedicada para cada específica (hoja en el árbol de categorías) categoría de producto con atributos de categoría específica (como la resolución de los televisores) modelado como una columna separada.

Mientras performant esta configuración no es flexible si necesita añadir atributos a las categorías existentes o añadir nuevas categorías. Para cada tal cambio después de que se necesita:

• Alter / crear la tabla
• Nueva forma para el filtrado EL PLAZO dicha categoría por atributos específicos
• Nuevo código para generar las consultas de base de datos para la búsqueda y filtrado
• Algunos de los nuevos ViewModels / dtos y puntos de vista para la presentación de productos de nuevas categorías

Para hacer frente a esa complejidad Creo que se necesita algún tipo de representación meta de esos atributos (incluso fuera de la aplicación) en XML o incluso archivo de Excel, de manera que en cada cambio de todo el código mencionado se podría generar auto-(SQL / consultas ORM, código de la aplicación, plantillas). Por lo que puede ayudar con el desarrollo, pero aún así las pruebas y se necesita el despliegue adicional.

En ese momento me he enterado de que eBay en realidad no usar db relacional para la búsqueda, y que su taxonomía es tan flexible, que se puede añadir con bastante rapidez nuevas categorías de hojas. También sus categorías no son probablemente categorías de un árbol jerárquico modelado en dB de relación, pero sólo atributos de búsqueda (facetas).

Después de tener un vistazo rápido a la configuración más prometedora dedicada facetas de búsqueda (instancia separada Solr) No estoy seguro de si me podía ayudar en ser flexible a los cambios de la taxonomía ya que normalmente Solr simplemente refleja de alguna manera DB relacional, atributos específicos categoría por lo haría todavía tiene que ser modelado en DB como DBMS metadatos, así por ejemplo. formas de generación de interfaz de usuario dinámicas para los atributos de filtrado sería difícil a menos que:

1) Me gustaría mantener los datos en RDBMS usando fasion EAV y superar sus problemas de rendimiento con el uso de la búsqueda SOLR (pero todavía habría problemas con desorden EAV, sin aplicación de la integridad de datos, etc)

2) Me gustaría mantener sólo el diccionario de atributos (es decir. Sólo sus nombres y tipos) en RDBMS y almacenar los valores de los atributos específicos en SOLR usarlo como una especie de almacén de datos no relacionales, aparte de servicio de búsqueda. No estoy convencido de que esta solución sea (incluso si es posible) ya que la aplicación se acoplaría a firmemente con Solr (es decir. Edición del producto de administración CRUD interactuaría con SOLR directamente).

¿Cuáles son sus pensamientos? ¿Cree que para cualquier tipo de tales (performant) la generación de código de taxonomía flexibilidad es inevitable? ¿Qué haría usted eso? Tal vez algún diccionario de datos separada en la moda EAV en el PP sólo para fines de generación de código? Supongo que también podría utilizar algo como MongoDB, pero la generación de código de interfaz de usuario (en tiempo de ejecución o no) seguiría siendo necesario algún tipo de metadatos.

Hay muchas preguntas aquí, pero yo no quería a dividirla en preguntas más pequeños ya que estoy interesado en un enfoque de diseño en general cuando se trata de una clase más grande de este tipo de problemas.

Answer 1

No pretendo tener una respuesta definitiva a todo esto (que es una pregunta bastante abierto que usted debe tratar de romper en partes más pequeñas y que depende de sus necesidades reales, de hecho estoy tentado a voto para cerrarla), pero voy a comentar un par de cosas:

1. I se olvidaría de modelar esto en un RDBMS. facetadas de búsqueda simplemente no funciona en un esquema relacional .
2. OMI este no es el lugar adecuado para la generación de código. Debe diseñar su código por lo que no cambia con los cambios de datos (no estoy hablando de esquema cambios).
3. El almacenamiento de metadatos / atributos en una hoja de cálculo Excel parece una idea muy mala. Construiría una interfaz de usuario para editar este, que se almacena en Solr / MongoDB / CouchDB / lo que usted elige para manejar esto.
4. Solr no "solo espejo relacional DB". De hecho, Solr es completamente independiente de las bases de datos relacionales. Uno de los casos más comunes es de datos de dumping de un RDBMS a Solr (desnormalización de datos en el proceso), pero Solr es lo suficientemente flexible como para trabajar sin ningún tipo de fuente de datos relacionales.
5. facetado jerárquica en Solr sigue siendo un tema abierto en la investigación. Actualmente hay dos enfoques separados en fase de investigación ( SOLR-64 , SOLR-792 )

Answer 2

¿Y si tuviera diferentes tipos de categorías para los diferentes tipos de productos?

Tomando el ejemplo de eBay, tendríamos Productos que puede ser Libros o TV / Pantallas .

Los libros tienen título y el ISBN, y pueden estar en la categoría de ciencia ficción, o en la categoría erótica, o en la categoría de no ficción, o categoría autobiográfica. O tal vez usted tiene un libro que se encuentra en la no ficción, categorías eróticas autobiográficos.

Muestra tienen resolución de pantalla y el consumo de vatios-(?), Y pueden estar en la categoría de pantalla plana, categoría CRT, o categoría de alta definición.

Desde un punto de vista puramente relacional, podrías tal vez modelo de este modo:

[Product]-(1)------(1)-[  Book  ]-(n)------(m)-[ book_category ]
| id    |              | title  |              |  name         |
| price |              | ISBN   |
| ...   |
| ...   |-(1)---(1)-[   display  ]-(n)------(m)-[ display_category ]
                    | resolution |              |  name            |
                    |   watts    |

En lugar de attributes dependent on a particular product category modelado, que tendría diferentes propiedades y categorías depende de la Tipo / clase del producto.

supertipos y subtipos