I’m trying to design a scaleable approach to modeling a social photo gallery and user profiles.
Every profile will have 1 gallery.
My current idea is the following:
- Photo table (id, photourl, fKey userId, fKey emailId)
- Profile table (id, username, fKey userId, fKey emailId)
- User table (id, fKey emailId[])
- Email table (id, publicKeyAddreess)
- Edge table (id, fKey1, fKey2, entity1Type, entity2Type, relationship: ENUM, weight: string, hide: bool)
Basically every user can have multiple emails. Each email can have multiple profiles. Each profile should be able to display its owner’s photos in a reorderable gallery.
I’m currently thinking of using the edge table to create edges (like a graphDB) to represent ownership between photos and a Profile. Profiles can feature photos they uploaded or photos other users uploaded.
The feature in the profile would comprise of an edge relationship between the photo table and the profile table. Obviously if hide = true, the photo is hidden from public view but still shows up in edit mode for profile owner. The weight is basically a string that is sorted alphabetically so maybe 3 photos are weighted in order: 1: a, 2: b, 3: c; if we want the third photo to reorder to order 2, the new weights could be: 1: a, 3: aa, 2: b
Any ideas on this? I built a prototype but it’s a bit slow. I’d like it to scale to be able to handle tens of thousands of photos / profile.
It’s particularity slow on the initial import process of a user has multiple profiles (let’s assume 100 profiles for argument, and maybe 100,000 photos).
In this setup, I’m creating 100,000 x 10 edges for each profile since each profile could have a different custom order. I also need to be able to handle updates to this setup if the profile owner decides to upload new photos and delete existing batches. Obviously these numbers are quite large but the idea is that I’m seeing degraded performance for thousands of photos right now so any pointers highly appreciated.
