Cómo implementar campos definidos por el usuario y agrupamiento para la aplicación multi-tenant: EAV, patrón de tablas fijas, NoSQL

Question

Estoy trabajando en un SaaS, donde cualquier inquilino puede tener varias listas de contactos, cada lista puede tener cualquier cantidad de Los contactos de los campos personalizados de esta lista pueden almacenar y cualquier cantidad de grupos que puedan incluir los contactos de la lista (los grupos se utilizan para segmentar los contactos de la lista). Cada contacto tiene uno de los campos obligatorios: dirección_de_email y cualquier cantidad de campos definidos por el usuario que estén definidos para la lista en la que se encuentra, como mencioné anteriormente. Debemos ser capaces de encontrar contactos de las listas basadas en los grupos en los que se encuentran y los valores de los valores definidos por el usuario. Debemos provisionar hasta 30 campos definidos por el usuario. ahora veo tres formas de resolver este problema:

1. Usando tipo de EAV (tratamos de hacerlo de esta manera), pero parece bastante complejo. Tenemos una tabla de listas (listas de inquilinos), tablas relacionadas custom_fields, una tabla relacionada de suscriptores que almacenan email_addreses de suscriptores de la lista, tabla subscribers_custom_data que está relacionada con los suscriptores y custom_fields tablas (valores almacenados de los campos personalizados de los suscriptores).

2. Patrón de tablas de campo. Las descripciones de esto están aquí http://blog.springsource.com/arjen/archives/2008/01/24/storing-custom-fields-in-the-database/. En este caso, usaríamos un campo relacionado con campos personalizados, que almacenaría en columnas todos los campos personalizados, por ejemplo, 30 columnas para almacenar los valores de cada campo personalizado y una tabla que guardara la asignación del nombre y nombre de la columna del usuario campo definido Parece complejo también. Tendríamos que tener al menos 30 índices al menos para buscar por los valores de los campos personalizados, también hay otros problemas,

3. Para usar algún tipo de base de datos NoSQL al menos para almacenar campos definidos por el usuario y quizás grupos de la lista. ¿Cree que estas bases de datos pueden ser útiles aquí y, en caso afirmativo, cómo diseñar para almacenar campos y grupos personalizados? Intento ver diferentes tipos de NoSQL, por ejemplo, documento orientado como MongoDb, pero de inmediato no veo cómo puede ayudar a resolver este problema. Aquí podemos almacenar atributos arbitrarios, pero para buscar los valores de los campos personalizados necesitamos indexarlos con anticipación, así que tenemos que saber qué campos personalizados tendremos.

Gracias por cualquier información al respecto.

Answer 1

Si desea que todos los campos se indexen todo el tiempo, pruebe con una tecnología como Apache Solr que lo indexa todo. El objetivo principal de Solr es ser un motor de búsqueda de texto completo, pero básicamente es una base de datos orientada a documentos.

Éstos son comentarios acerca de otras opciones:

1. EAV no es bueno, y yo estoy en contra de usarlo. Rompe muchas reglas del diseño de bases de datos relacionales, y no se escalará. He escrito mucho sobre esto en Stack Overflow, así que busque my answers bajo la etiqueta eav.

2. No necesita solo 30 índices: necesita hasta 30 índices factoriales para manejar cualquier posible combinación de índices. Tenga en cuenta que puede crear índices de varias columnas, y estos tipos de índices son importantes para admitir ciertas consultas. Por supuesto, esto es totalmente impráctico para crear tantos índices; necesita crear índices para que coincidan con las consultas para las que desea optimizar. Si no sabe qué campos tendrá y qué consultas tendrá contra ellos, no podrá optimizarlos.

3. Las bases de datos orientadas a documentos como MongoDB/CouchDB no son mágicas, sin importar lo mucho que sus defensores traten de afirmar que lo son. Requieren que indexe documentos para búsquedas rápidas, y eso significa que necesita conocer los campos indexables de un documento.

   Crear un índice en el tiempo de ejecución es un problema, ya que puede llevar mucho tiempo, dependiendo de la cantidad de datos que hay que indexar. Tendrá que encontrar la manera de ejecutar la creación del índice "fuera de línea" (es decir, no hacer que el usuario lo espere durante una sola solicitud http) y luego notificarlo cuando esté completo.

4. Debe leer sobre How FriendFeed uses MySQL to store schema-less data. Usan un LOB serializado, básicamente combinan todos los atributos personalizados en un blob XML o JSON. Por lo tanto, los usuarios pueden crear cualquier cantidad de campos personalizados adicionales en cualquier momento que deseen. Pero antes de que un campo personalizado determinado se pueda buscar, se crearía una tabla secundaria que haga referencia a las filas en las que ese campo contiene un valor determinado. De este modo, obtiene un índice que es solo tan grande como el número de instancias de un campo personalizado definido por el usuario. Y no necesita hacer cada campo que se pueda buscar.