I have a Firebase database with the following structure
Stories
Cards
Photos
Users
Relationally, each story has multiple cards, which in turn have multiple photos.
Is it possible to use the Firebase REST API such that when I make an API call to get a list of stories, it will also include the related children Cards and Photos?
https://[project].firebaseio.com/stories.json?print=pretty
Note that in the firebase database, these are not nested within the parent, but as separate lists.
Unless there is more information, from your comment, it appears your data is all 1-1 relationships and in that case, there's no reason to separate it out.
So structure your data
Stories
Cards
Photos
Users
when you load a story, it loads the cards and photos that go with it so with once observe, you get everything needed.
That being said... Denormalization is generally a the way to go when the data has anything other than 1-1 relationships or if it's more complex than in this question.
Related
This article was written using a translator.
There are many products in my company.
Like Atlasian, I want to create a service that allows my company's products to move pages only for the products that customers have.
In order to do so, you need to know the products of each customer, and I need to make sure that only those products can be clicked, but can you not use the database?
Using the database makes it so complicated that I want to implement it as simple as possible.
You need to know a programming language/ framework that allows you to create a service/api.
There are various ones available.
Search on the internet.
The architecture of a service is slightly different from directly having a data entry form that stores into a database.
Most apis'/ service entails you creating classes to do CRUD operations(i.e create,read,update and delete operations) by coding classes and then consuming the API into the application.
So yes you can have within the API classes that can be called and then used to store information that the customer has installed into a database, and also retrieve product values specific to a specific customer.
See API as mid layer between front end,and database
This should be a pretty common issue: let's say I'm updating a users table as well as a users_organizations table. From the UI perspective, there is only one button "Save".
I can either:
1) Create a single API route
2) Create one API route for each resource (one for users, one for users_organizations)
And then, suppose I choose 1). Should I update both tables in a single database call or should I split it up into 2 database calls?
In general I'm never sure how to approach these problems. Sometimes there's an action that affects more than 2 database tables at once. How do I ensure robustness, proper error handling, and keep my code sane all at once?
Definitely a problem I struggle with as well.
From what I've seen in the past, most operations that go along with a UI action are related, and can be given a common action name like update-user when clicking "Save". I'd have a single API endpoint to update the user, such as PUT /api/users/123 in a REST API. The body of that request would contain updated fields and new organizations the user belongs to.
Then on the server side I would make 2 database calls, one to update the user table and one to update the user_organization table.
If you feel 2 operations are so different that it's difficult to come up with a common API endpoint name, or if they need to be called independently in other parts of the app, I would argue that they should be 2 different API endpoints.
At the end of the day I try to ask, if a new developer were to try to understand this code, what would be the simplest approach?
I'm learning couchDB ,and decided to build a bookmark manager as a practice project.
I'm a little stuck in RDBMS ways of thinking and keep wanting to creat documents as if they were tables.
So I'm wondering if this approach is "correct" in terms of using document database like couchDB?
Each document contains user data, I name the document user12345612345.json and then structure the data inside like this:
{
"username":"todd",
"password":"hSnxS987sDJf77600sHjdyDhskJShdskshjS75sa765sa"
"bookmarks":
[
{
"url":"http://www.hello.com",
"title":"Hello website"
},
... etc...
]
}
So, I am storing all bookmarks for one user in a single document. That way, I can load this on login, and manage the data, and if there is an update, I update that one document.
I'm thinking with a number of users, if I stored each bookmark as a document, that would be zillions of documents that would need to be indexed by user - not sure that would be the right approach.
My next step is to add folders and tags. I'm thinking I would simply add those arrays into this user document.
Right?
You are doing the right thing. The biggest mental step you need to take when moving from structured to "less structured" is that you keep object properties together. So if a user is unique and bookmarks are associated to that user, keep the user and the bookmarks together like you are doing now.
Same for your users and tags. Think about what you are doing in your applications. Probably you would like to retrieve a user with his bookmarks, tags, folder, etc in just one call instead of going over several tables, joins, etc. That's the beauty of NoSQL. ;-)
I've got several pages about products that I want to load into a database and instead of creating a separate html page for each product, I was thinking of creating a single page that will display whatever product the user clicks on. Each product page will have a similar structure with its name, picture, description, bullet points for features (varies from product to product), price.
My question is if I want to store all those information in a database (I imagine I would need a different field for each paragraph, picture, name, each bullet point, etc) is there a way to get around that? To store all those information in a single field or as few as possible and still keep the formatting. It seems like I would be overloaded with the number of fields I have to manage.
I'm starting to doubt if this was even a good idea to begin with...
Do not store all that information in a single field. If you are going to do that, then just create the HTML page and save yourself the trouble of having a database that you aren't properly utilizing.
What you need to do is identify the relationship between all parts of your page. For example, if a single product can have multiple photos you would want to define a multi table relationship that defines a one-to-many relationship between the Product and ProductImage tables.
Grasping how relational databases relate to the data you are working with can be difficult at first and it might pay off to hire someone for a few hours to go over what you are trying to do and how to implement this effectively using a DB. Since it is a real world example for you it will be an excellent way to learn. Good luck!
You're not the first person to want to do something like this. It's a very common problem that has a well established solution. You need to use what's called a web content management system. WCMSs allow you to use a common template throughout your website while filling in specific stuff for each page. I recommend Joomla because it's easy to setup, easy to use, and most web hosts support it. But you can also look at stuff like Wordpress or Drupal. Wordpress is more blog centric though and Drupal has a steep learning curve.
My app has windows that are components. In my case, now I have 2 components that have a drop down list that show the current logged user lists. So when I use one component for the first time it make a request to database, save data in model, and load data from model, but when the second component opens, it will just load data from model. Easy for now:
ListModel: this contains the current user lists.
Now I have another component but this needs the lists of another user. Where do I save these lists? I can't put in the ListModel as then will mix up with current user.
Just a remind: there is not just 2 users. It might have more users, so it should be scalable.
Then another problem that will solve both:
Each list has items. They will be saved in ListItemModel?
How to make to not mix between lists. So items from ListX doens't mix up with items from ListY?
thanks
Don't be timid with the models. Use as many as you need to model your data for effective use. You can model the same data in several different ways. If you find commonality between models, extract a base class for them to use