I'm using directus for the first time. According to the documentation, database joins are possible. However, there is nothing about usage in the documentation, just a note to add this in future. Does anyone of you know how to use it anyway?
You can setup a relational interface (like a many-to-one) to connect two collections. When that's setup you can use the fields parameter to select how many "levels" deep you want to retrieve the relational data.
Let's say you have a collection books and a collection authors. In this example, each book has a single author. Using a many-to-one interface in the books collection, you can now select what author wrote the book.
To fetch the books, you'd normally use /items/books. To retrieve the title of the book, and the name of the author, you can get /items/books?fields=title,author.name.
If you want all the data, you can also use the * flag: ?fields=*.* will retrieve all fields 2 'levels' deep.
Related
I've built a RESTful API that fetches employees from the database, Now I want to implement search functionality that filters employees by name and then fetches it. In the frontend, I've fetched employees and then based on user input I'm converting both user input and result from db to lowercase and then matching for similarity? Do you think this problem can be approached in a different way? any other strategies? thanks
Yes, let the database do the comparison for you in SQL. Less resources will be used throughout the entire stack. One of the main features for databases is searching for specific data. Also SQL is case insensitive so no need to do a toLowerCase.
SELECT *
FROM Employees
WHERE name LIKE '%SearchValue%'
Only select the columns you need.
My application consists of users posting content and interacting with each others. It's a twitter like containing a news feed populated from the persons they follow.
I would like to display the posts from the direct followers, and optionally going deeper (followers of followers, etc...).
What king of implementation, using MongoDB, would you suggest ?
It seems like a good candidate for graphs, using the graphLookup aggregation stage. I thought about using 3 collections :
users : containing users name, phone number, etc...
relationships : this collection would contains every user's relationships
posts : containing posts
The idea is to have one collection modelling relationships (relationships), and use it to select any other content from a person's network. In the example it's about posts, but some more content could be added in the future (coming from other collections). The goal is to keep separated the relationships from the other collections.
I'm looking for an efficient way to do this king of queries using MongoDB.
TLDR: need standard/framework to accomplish such a query /courses?teacher.age=30 over multiple resources (course, teacher).
We are using Spring Data Rest to expose our relational database tables in a hateoas format. The entities are published as REST resources.
Now, the users would like to search over multiple resources.
For example "give me the names of all courses given by a teacher of 30 years old".
Because we need courses, this would be a search operation on /courses.
However, the age of a teacher is on /teachers.
So in 2 steps:
/teachers?age=30 which have _links to courses. Then, every course can be opened to inspect it's name (eg: /course/942).
A more intuitive operation would be to directly call /courses?teacher.age=30.
This is what we would like to accomplish.
Of course, we can implement this by hand. But the real question is: are there already existing standards (and popular libraries) to accomplish this?
We would like to find a scalable solution, where not every attribute (to search on) has to be added manually.
This dot-notation is just a way of representing the query. It is not a requirement of a standard/library.
Characteristics of our application:
relational database (postgres)
json api
hal/hateoas
I'm creating a discussion system using Parse.com
In my [simplified] system, there are Posts, Categorys, and Comments.
As you probably imagined, Posts can belong to one or more Categorys and can have multiple Comments.
However, often users will want to see all the Posts in a Category. If I set up my database like this
Post (name, content, categories)
Category(name)
I am worried that querying for all the Posts in a Category will be very ineffeficient (since it will have to check the categories field of every Post.
However, if I design the database like
Post (name, content)
Category(name, posts)
it will be inefficient for me to query what Categorys a Post belongs to since it will have to search all the Posts arrays in the all the Categorys.
I'm sure this must be a common Database design dilemma but I am still new at this. What is the best way to approach and solve this problem?
What you're looking for is a bi-directional, many-to-many relationship between Post and Category. With Parse, there are at least three approaches you can take.
You can add a column as a PFRelation to the Post table. You can ask a Post for its categories relation, create a query from that and run it. Inversely, if you have a category you can create a Post query with a where clause on the categories key. PFRelations are good if you will have big collections.
If you think better as a relational model, just create a "join" table called CategoryPosts. It would have two pointer columns, one for the Post and another for the Category. This is also very efficient.
Lastly, you could add an array column to either class. Since all of the results are loaded at once, this works best for smaller collections.
These options are described in a little more detail in the Parse Relations Documentation.
so I'm working with a database that has multiple collections and some of the data overlaps in the collection . In particular I have a collection called app-launches which contains a field called userId and one called users where the _id of a particular object is actually the same as the userId in app-launches. Is it possible to group the two collections together so I can analyze the data? Or maybe match the the userId in app-launches with the _id in users?
There is no definit answer for your question Jeffrey and none of the experts here can tell you to choose which technique over other just by having this information.
After going through various web pages over internet and mongo documentation and understanding the design patterns used in Mongo over a period of time, How I would design it depends on few things which I can try explaining it here in short.
if you have a One-To-One relation then always prefer to choose Embedding over Linking. e.g. User and its address (assuming user has only one address) thus you can utilize the atomicity (without worrying about transactions) as well easily fetch the records without too and fro to bring other information as in the case of Linking (like in DBRef)
If you have One-To-Many relation then you need to consider whether you can do the stuff by using Embedding (prefer this as explained the benefits in point 1). However, embedding would help you if you always want the information altogether e.g. Post/Comments where your requirement is to get the post and all of its comments by postId let say. But think of a situation where you need to get all the comments (and it related posts) which contains some specific tags in comments. in this case you should prefer Linking Because if you go via Embedding route then you would end up getting all the collection of comments for a post and you have to filter the desired comments.
for a Many-To-Many relations I would prefer two separate entities as well another collection for linking them e.g. Product-Category.
-$