La siguiente es una tabla de información de miembros, donde WxId es la identificación de la cuenta oficial de WeChat (porque diseñé este programa para admitir varias cuentas oficiales de WeChat), UserId es la identificación del miembro actual y el Pid en la figura a continuación es el último miembro. ID de usuario de nivel
Echemos un vistazo a los datos:
De acuerdo con la figura anterior, el Pid del miembro con ID de usuario = 1 es 0, lo que indica que el miembro es de nivel superior y nadie lo promueve. El miembro con ID de usuario = 2 tiene un pid de 1, lo que significa que es promovido por un miembro con ID de usuario de 1. Luego mire al miembro con ID de usuario = 7, su pid = 2, lo que indica que el miembro con ID de usuario = 2 lo promueve. Para decirlo sin rodeos, la relación de promoción es:
idusuario(1)->idusuario(2)->idusuario(7)
idusuario(1)->idusuario(3)
idusuario(1)->idusuario(4)
idusuario(1)->idusuario(5)
idusuario(1)->idusuario(6)
Luego, queremos consultar todos los miembros de promoción de primer nivel de un miembro (suponiendo que su id sea 1), el sql correspondiente es: select * from t_user where Pid=1, aquí no hay problema, no es difícil
Luego continúe, si desea consultar sobre sus miembros de distribución de segundo o tercer nivel, será problemático y necesitará usar un subbucle. El código correspondiente es el siguiente:
Cadena pública obtiene (int pid) {
StringBuffer sb=nuevo StringBuffer(sb);
ArrayList list=(ArrayList)DaoFactory.getUserDAO().exe("select id,Pid from t_user where Pid="+pid);
for (Iterator iter = list.iterator(); iter.hasNext(); ) { DataField df=(DataField)iter.next();
sb.append("<li>"+df.getInt("id")+"</li>");
// llamada recursiva
sb.append(obtiene(df.getInt("id")));
}
}
Como se vio anteriormente, la solución principal es llamar recursivamente. Aunque la función también se puede realizar, pero en el caso de un número relativamente grande, es fácil causar problemas de rendimiento (aquí es solo para encontrar miembros, si las estadísticas de consumo e ingresos de los miembros en cada nivel deben consultarse con el tabla de consumo, el rendimiento no sé cuándo terminará la tarjeta).
Aquí viene el punto importante. Rediseñemos la tabla. Aquí lo resolvemos principalmente a través del diseño de la base de datos. Sabemos que la cantidad de almacenamiento de la base de datos no tiene mucho miedo, por lo que pensamos que puede ser así. Cada vez que un usuario promueve a un miembro , enviamos una tabla (Temporalmente llamada tabla de relación de usuario) ¿No es suficiente escribir su nivel de relación? Por ejemplo, a promueve a b, luego b promueve a c y c promueve a d, por lo que escribiremos un registro en la base de datos para registrar la relación de tres niveles por encima de b.
Mira los datos de la tabla
En la figura anterior, además de la tabla de membresía original, hemos agregado una nueva tabla de relación de membresía: t_user_relations
Como puede ver aquí, el miembro con ChildId=2 es un usuario de distribución de primer nivel (FxLevel=1) con id 1 (Pid=1)
Para el miembro con ChildId=7, hay dos registros en la base de datos, uno es: es un usuario de distribución de primer nivel (FxLevel=1) con id 2 (Pid=2), y tiene id 1 (Pid=1 ) Usuarios de distribución secundaria (FxLevel=2), por lo que no es difícil entender que si un miembro tiene tres niveles, aquí debería haber tres registros. El entendimiento simple es que cuando se agrega un nuevo usuario, la información del usuario correspondiente a todos los niveles por encima del usuario se registra en la tabla de relaciones de usuario.
De esta forma, cuando queramos consultar todos los miembros de primer nivel de un miembro, podemos usar sql:select * from t_user_relations donde Pid=1 y FxLevel=1
Todos los miembros secundarios sql:select * from t_user_relations donde Pid=1 y FxLevel=2
Todos los miembros de tercer nivel sql:select * from t_user_relations donde Pid=1 y FxLevel=3
Cuando necesitamos contar el consumo total de los miembros de tercer nivel, es muy conveniente usar sql:select sum(t_pay.Money) from t_user_relations,t_pay where t_user_relations.ChildId=t_pay.Userid and t_user_relations.Pid=1 and t_user_relations. FxNivel=3
De manera similar, consulte el consumo de miembros secundarios: seleccione sum(t_pay.Money) from t_user_relations, t_pay where t_user_relations.ChildId=t_pay.Useid and t_user_relations.Pid=1 and t_user_relations.FxLevel=2
¿Cómo comprobar el consumo de todos los submiembros? No puedes escribir tres sql, por supuesto que no. ¿No es suficiente usar la condición FxLevel>0 :)
seleccione sum(t_pay.Money) de t_user_relations,t_pay donde t_user_relations.ChildId=t_pay.Useid y t_user_relations.Pid=1 y t_user_relations.FxLevel>0
Tal sql está resuelto. Si usa el enfoque recursivo con el que comenzó, la velocidad será muy, muy mala a medida que crezca la cantidad de datos.
También puede hacer una pregunta arriba, así que si sabe quién es un determinado miembro en el primer nivel y de quién es el segundo nivel,...? Esto necesita usar la tabla diseñada por el primer método. Como puede ver, todavía necesitamos usar el diseño de la tabla anterior :)
seleccione Pid de t_user donde id = 2
if(Pid!=0) indica que no es el nivel superior, continúe comprobando. Aquí puede usar una consulta recursiva o hacer tres consultas (dependiendo de si el pid es 0, por lo que algunas pueden ser solo una o dos consultas, hasta 3 veces), tenga la seguridad de que esto no afectará demasiado el rendimiento y puede ignorarse .
O coloque los datos de identificación y pid en el caché, redis es una buena opción. Puedes probarlo.
Finalmente, mire el efecto del desarrollo parejo :)
