Which approach is better with database design?


I am trying to choose one of the two options I show in the image. I would appreciate it if you could tell me which option you think is more logical and better.

I don’t know if there would be an advantage or disadvantage to splitting data, especially as in the second option. Because I will have to select and calculate documents from different collections to calculate the expenses. I doubt this is a good option.

On the other hand, in the first version, the fields in the plan change according to the plan types. It’s ok for NoSQL, as it doesn’t have any schema. But I want to use a single model while decoding data.

I was unsure between the two options :slight_smile:

Thank you.

@ben Hi, nobody answered :slight_smile:

I want to prepare the following reports. The information I need is written next to them. Which approach would be better for these types of queries?

That’s probably because it’s the weekend.

You can forget the days when you are home every day. I never noticed it was the Weekend. Sorry, you are right …

1 Like

Isn’t that the truth!

I’m not sure I understand the particulars of all the diagrams BUT what I can try and help with is some general guidance: You can think of fauna as a giant distributed hash table of documents keyed on References. No reference, no access. We also have indexes which you can think of as Hash[Terms, SortedSet[Values]], with the same kinds of costs for access. So a general pattern when dealing with hierarchical data is to have an parent document, and then have child documents that embed the parent id. Then an index with the parent id will give give access to the set of child documents with those parents. That access pattern will always be efficient no matter how large the collection gets.

When it comes to aggregations, depending on how large they are you might want to maintain them inline in the documents or use Count, Sum and friends. Be warned though: they are O(n) in the size of the set, we don’t keep automatic statistics (yet).

As a result, it makes more sense to split the data, considering that functions such as Sum, Count perform depending on the number of documents. Therefore, I chose the second method, although it will cause me to write more code.

Thank you for your time.

One quick precision: they are O(n) in the size of the selected set. So as long as the index has high selectivity count is fine on a massive set, as long as your index zooms into a much smaller one.

1 Like

I read the documentation in detail. It says that the larger the set selected for the sum process, the longer the process takes, and maybe it could fall into timeout.
This method came to mind.

Is it a good practice to do Add, Remove and Delete operations through functions and change the Total Amount field in the related plan according to these operations?
What do you think about that?

This accurate. All I was trying to stress is that if you have a collection with a million docs in it, but your match selects 100, count will work fine.

This can work very well as long you don’t contend too hard on a single document to do it.

Thanks for your help

Hi hasimyerlikaya, i’m comparing performance between my sql and faunadb, when i import one csv file have 1 milions row to my sql, it take 12s, but when import import in faunadb, i waited about 10 minutes but it’s not finish and when show on dashbroad , it only show 100 results, i can’t know extractly how many time it take, can you help me this problem ? thank so much

I’m also just interested in Faunadb. Honestly, I don’t have much competence about it.