I was trying to find out the maximum count of list items that can be provided in ndb.IN query for equality comparison, but documentation does not state the same anywhere.
Here's What I am trying to implement?
I have a list of users, which have some relation to the actual user. I also have a Feed items, which I want to be sorted in the terms of relation between the user and the Feed creator.
To do the same, I thought of 3 different types of queries:
1. Feeds which belong to users with direct relations
2. Feeds which belong to users with indirect relations
3. Feeds which belong to users with no relations.
I want to know if there's a better approach to do the same.
Related
I am currently exploring MongoDB.
I built a notes web app and for now the DB has 2 collections: notes and users.
The user can create, read and update his notes.
I want to create a page called /my-notes that will display all the notes that belong to the connected user.
My question is:
Should the notes model has an ownerId field or the opposite - the user model will have a field of noteIds of type list.
Points I found relevant for the decision making:
noteIds approach:
There is no need to query the notes that hold the desired ownerId (say we have a lot of notes then we will need indexes and search accross the whole notes collection). We just need to find the user by user ID and then get all the notes by their IDs.
In this case there are 2 calls to DB.
The data is ordered by the order of insertion to the notesIds field in the document.
ownerId approach:
We do need to find the notes by their ownerId field across the notes collection which might be more computer "intensive".
We can paginate / sort the data as we want - more control over the data.
Are there any more points you can think of?
As I can conclude this is a question of whether you want less computer intensive DB calls vs more control over the data.
What are the "best practices"?
Thanks,
A similar use case is explained in the documentation. If there is no limit on number of notes a user can have, it might be better to store a userId reference field in notes document.
As you've figured out already, pagination would be easier in the second approach. Also when updating notes, you can simply updateOne({ _id: "note_id", userId: 1 }) instead of checking user's document if the note actually belong to the user.
I am designing a Database management project of gym management. There are 2 users, one is the clerk who can add,remove and edit all trainers, centers and members and the second user is the member who can only see and edit certain attributes related to him. Member ,center and trainers are 3 entities in the ER diagram so the question should I introduce entity for clerk and if so should it have a relationship with any of the three entities described above?
I wouldn't split up the two Entities based on the Fact that they have different permissions in your system.
I recommend you focus on the concepts behind the entities:
First, if all Attributes are equal I would start considering building 1 Entity out of the two. Once you end up with multiple columns that are mainly null it might have been a mistake to "merge" two entities.
In addition to that you should check if there is a central name that you can give your merged entity. For example if you have the two Entities: Manager, Employee and you want to merge them I would maybe just call it User and check if the Properties still make sense in that context.
Last but not least you should think about how the Entities are used later in the development. If you need two Joins instead of one once you split up your Entities that could be an argument for merging them. Maybe later in the development your 'clark' Entity will be extended by a few columns, this way you might end up with null columns again.
I think a general answer is not suitable since the Domain is unclear. Just collect arguments for and against merging the entities and compare those.
I am building a social media app in which each user can follow an indefinite number of other users.
According to this website, there are two ways of building this relation in the code. Either by Two Way Embedding or One Way Embedding.
One Way Embedding is to be used if the relation is asymmetric. I.e: Model A can have a huge number of Model B whereas Model B has a very limited number of Model A.
Two Way Embedding is to be used if the relation is somewhat symmetric. I.e: Model A has almost as many Model B as Model B has model A.
This is in order not to exceed the size limit of a document.
Check the linked website for more details.
The problem with my project is the relation is between the model and itself.
In other words, the model is User and it can follow other Users.
So, a user will follow a big number of other users, the size of his document might exceed the size limit.
So the question is:
Should I implement the Many-To-Many relation without using the embedding approach?
Use a separate collection for links between users, reference both user ids from that collection.
i'm needing some help with setting up the proper relationships for my project.
The best way I can compare it is by considering a student timetable.
I need a user to be able to have many classes, and tasks within each of those classes. However, these tasks should also be linked to the user directly. I want to be able to call $user->tasks() and get all the tasks, rather than going through each $user->period.... The user has many periods, each period has many tasks, but the tasks should belong to user directly.
Any suggestions? Would i need to employ polymorphic relations in my table structure?
Thanks in advance.
It seems like what you need is the "Has Many Through" relationship.
From the docs
The "has-many-through" relationship provides a convenient short-cut
for accessing distant relations via an intermediate relation. For
example, a Country model might have many Post models through an
intermediate User model. In this example, you could easily gather all
blog posts for a given country.
In your case, it can be described as "the user has many tasks through period".
I am writing an application in Google App Engine with python and I want to sort users and user posts into groups. Users will be able to tag a post with a group ID and then that post will be displayed on the group page.
I would also like to relate the users to the groups so that only members of a group can tag a post with that group ID and so that I can display all the users of a group on the side. I am wondering if it would be more efficient to have a property on the user which will have all of the groups listed (I am thinking max 10 or so) or would it be better to have a property on the Group model which lists all of the users (possibly a few hundred).
Is there much of a difference here?
Your data model should derive from the most likely use cases. What are you going to retrieve?
A. Show a list of groups to a user.
B. Show a list of users in a group.
Solution:
If only A, store unindexed list of groups in a property of a user entity.
If both, same as above but indexed.
If only B, store unindexed list of users in a property of a group entity.
NB: If you make a property indexed, you cannot put hundreds of user ids in it - it will lead to an exploding index.