Designing a graph like DB In my case, I have 5 directions: 1:North, 2:South, 3:East, 4:West, 0:Unknown. A user can stand in one direction of another user. If he is not standing in any direction, he will be considered in the unknown direction.

A, B, north
A, C, north
A, D, north
A, E, south
A, F, south
A, G, south
B, A, south
B, C, south
B, K, east


In the above table, B, C, D are standing in north direction of A and E, F, G are standing in direction south of A and so on.

Expected operation frequency:


I expect hardly 10 updates in a month for a user
I expect max 1000 (300 in general) entries against a user in bulk.
I expect hardly 15 insertions against a user in a month
I expect hardly 10 deletions in a month against a user


Another way I can think to design the DB for the above situation

A, B, 1, 2
A, C, 1
A, D, 1
A, E, 2
A, F, 2
A, G, 2
B, C, 2
B, K, 3


or

A, 1, [B,C,D]
A, 2, [E,F,G]
B, 2, [A, C]
B, 3, [K]


But this design will make the find, and update operations a bit complex. How should I design the DB for the above situation?

Update

I'm trying to create a DB for a social website.


I'm expecting more than 1 million users in the next 2 years.
There would be around 2000 find queries against a user in a month.
If your primary concern is with the graph of user connections, then use a graph database. There are many out there. Some are graph-processing engines are built on top of existing NoSQL or relational products.

These products are specifically optimized for the friend-of-friend type of queries typical for social networks. The schema definition and queries are typically much simpler than the same rules implemented on a relational engine.