2010-07-29 9 views
9

Estoy diseñando una aplicación que implicaría que los usuarios "sigan" la actividad de los demás, en el sentido de Twitter, pero no tengo mucha experiencia con la base de datos/diseño/eficiencia de consultas. ¿Existen mejores prácticas para manejar esto, riesgos que evitar, etc.? Supongo que esto puede crear una carga muy grande en el DB si no se realiza correctamente (¿o incluso entonces?).'Seguidores' y eficiencia

Si hace una diferencia, es probable que las personas 'sigan' solo a un número relativamente pequeño de personas (pero una persona puede tener muchos seguidores). Sin embargo, esto no es seguro, y no me gustaría contar con ello.

Cualquier consejo recibido con gratitud. Gracias.

Respuesta

6

Bastante simple y fácil de hacer con total normalisation. Si tiene una tabla de usuarios, cada uno con una ID única, tendría una tabla TABLE_FOLLOWERS con las columnas, USERID y FOLLOWERID que describiría todos los seguidores de cada usuario como una relación uno a uno a muchos.

Incluso con millones de assosciations en un servidor de base de datos medio decente esto funcionará bien y rápido siempre y cuando esté utilizando una buena base de datos (IE, no MS-Access).

+0

Sé que ha sido durante mucho tiempo, me pregunto 'múltiples almacenar valores FOLLOWERID'would? – lazyprogrammer

1

Eso depende de cuántos usuarios espera soportar; cuántos seguidores espera que tengan los usuarios; y qué tipo de financiación/desarrollo-esfuerzo espera tener acceso si sus respuestas a las preguntas anteriores resultan ser optimistas.

Para un proyecto a pequeña escala probablemente ignore la base de datos, diseñe la aplicación como un modelo de objeto simple con objetos User que mantienen un List[followers]. Manténgalo todo en RAM para el funcionamiento normal y use un ORM para persistir a una base de datos periódicamente (probablemente postgresql o mysql).

Para un proyecto más grande, no estaría utilizando ninguna base de datos relacional; pero exactamente lo que usaría dependerá de los detalles específicos del proyecto.

Si solo está tratando de aumentar el concepto, vaya con el enfoque ORM; pero ten en cuenta que no se escalará.

+0

¿Te importaría señalarme en la dirección de algún material introductorio sobre el almacenamiento de objetos RAM? ¿De qué tecnologías estamos hablando, en particular? Algo como Redis? – Chris

+0

Para un pico, me refiero a mantener estructuras de datos simples directamente en la memoria RAM. Asumiendo 100,000 usuarios, con un promedio de 100 seguidores, y un simple ~ objeto de 100 bytes por usuario, y referencias de 4 bytes, solo necesita ~ 40MB para el gráfico seguidor y 10MB para el DB de usuario. Incluso con la sobrecarga de indexación de 3x, es algo que fácilmente puede caber en la memoria RAM y persistir sin demasiada dificultad en una base de datos. – Recurse

4

El modelo es bastante simple. El problema está en el tamaño de la tabla Suscripción; si hay 1 millón de usuarios y cada uno se suscribe a 1000, la tabla Suscripción tiene 1 mil millones de filas.

alt text http://www.damirsystems.com/dp_images/follower_model.png

+0

buen diagrama. Gracias. – user749665

+0

@Damir ... ¿podría explicar el sentido de "EnableSubscription" en su diagrama? ¿Eso es un bool? ¿Cómo debería funcionar esto de alguna manera, seguir y seguir? ¿Y por qué el uso de un bool? ¿No se puede usar una tabla dinámica y hacer referencia al ID de usuario como usuario y seguidor?¿Se utiliza EnableSubcription para prohibir que un usuario te siga? – Chriz74

Cuestiones relacionadas