New answers tagged database-design
2
It's fair for microservices to access other services for data. I'd look into the saga pattern for ideas how to deal with distributed data in a microservices architecture.
4
The point of microservices is to enable independent development and operation of parts of a larger software system. What is your goal in this project, what is the reason you are doing this?
A microservice is not a subtree of a data model. It is a closed, feature complete part of the whole, that has (ideally) no request-response dependency to other systems, ...
1
I would model this with a state change request table. It would refer to the object and the kind of change (publish, delete, replace content). If the request is approved, the state change is executed.
Special consideration would be needed when multiple state change requests are in flight.
-2
try this instead.
I would use the additional status field and i'll create dropdown so that maker can select "submit" and approver can select"approve" so that the same update will be done on my database
3
Your structure so far looks reasonable with a few caveats, so don't be too hard on yourself.
I wouldn't store any information about the components in the Products table directly if possible, so get rid of the part_list_id col. The product_id will give you the hook to build the component list later. This also means that you could add 'temporary' products to ...
2
Normally, for full historical tracking, you don't need the current status in a different table.
Instead, add two timestamps to your table which represent the start of the given time slice, and the end of the given timeslice. For an update, just set the end timestamp and insert a new row.
Something like this:
userid | status | validFrom | ...
0
While I aggree with Esben, that from a domain perspective the replies should be separate objects, you specifically ask about mongo, which is a totally different beast. For mongo, you should design your database not by looking at the storage of objects, but at the queries you make.
That being said, when you need to query a review together with its replies, ...
3
The standard technique for this sort of reporting work is to define the aggregates you need, and then compute them incrementally on a regular basis and store the results. Then, when the time comes to prepare the report, you assemble it (at least, as much as possible) from these stored results.
The computation of longer-range aggregates may itself use ...
2
You should store the replies as its own document because you can get scaling problems if storing with the review. This is an important part of DDD where it is called a consistency boundary.
I assume you want multiple users to be able to post a reply independently of each other. If you are storing them together you can risk some replies fail just because ...
0
I ended up using one Module collection inside a Lesson that holds everything including videos, audio, text and quiz modules instead of multiple Collections inside a lesson.
This meant I didn't have to build a nest of streams for each collection, which looked unmanageable when I tried to implement it.
I now just have a Module interface that handles ...
1
While trying to improve my applications' simple searches to bigrams and trigrams from unigrams, essentially, I saw your question.
If one of requirements is ability to query a distributed file system or database, then this might be interesting for you too:
the paper Pibiri and Venturini 2018
"Handling Massive N-Gram Datasets Efficiently"
outlines an ...
2
You are started off in the right direction with having separate tables for posts, images and videos, but your data model has gone awry in two ways:
Add a "post_text" column to your "posts" table and make it nullable instead of a separate "text_post" table. If this is optional (which it is for video and image posts) then the database can reflect that with a ...
1
If you have gone with a Heterogenous DB setup, you have only a couple of options.
1. Handle aggregations in the application:
I wouldn't mind doing this if the data is of small size or the response is small (for instance, deriving some data for a single logged in user from 2 sources) and you don't have to do multiple joins in the critical path of your ...
1
Generally you should design your data model to match the real-world requirements and not commit premature optimization. Hundreds of thousands of rows are not a challenge for a modern database engine.
Give some thought to what your partition key could be. Partitioning would keep your data logically in one set while allowing the database to optimize for ...
2
Having a separate pre-filtered list isn't that bad of an idea for many use cases and I imagine FB do use something like that for its News Feed.
For example, product recommendations on a web shop. You don't have time to do fancy AI every-time a user browses or adds an item to a basket. But you can premake lists of items that are similar to each other and tag ...
2
Yes, this is a decent way to handle this problem on the back-end side:
you handle each class as a distinct table (Post, TextPost, ImagePost and VideoPost),
you use composition to model the association between a Post and its specialistion XxxPost, with the Xxx_Post_id
The only problem is that if you add more post types, you will have to add more ids in ...
1
With your current model, you have to change a lot of stuff whenever you want to add a new post type:
Add a new _id column to the post table
Create a new table to store content for the new post type
Add a new field to your response structure
That doesn't seem very scalable to me. Instead, I would just store a type column in the post table indicating the ...
0
option #2 is the ideal choice. The overhead is not such that it requires consideration of other options. With this option, the database will remain organized and easy to understand.
Option #3 is faster than option #2 but it will require you to keep track of which integer means what. If for any reason if you want to change the number then it might require ...
Top 50 recent answers are included
