1) All data is relational, that's what makes it data. The question is really about whether you need to store it in different tables with a relational key (order header, order lines with a common order ID) or in a nested structure {
orderID: 1,
customerID:9876,
orderdate:2023-11-09,
lines: [
{
lineNumber:1,
itemcode:ABC123
},
{
lineNumber:2,
itemcode:DEF456
}
]
}
The order document above makes noSQL database reads very fast across the order, but if you want to aggregate data about items you have to scan the entire order collection or save the data in multiple formats. With the data in a RDBMS (SQL database) it is much easier to navigate in any direction (e.g. by customer, item, item type, geography or timeslice) the reads are more complicated to craft but data storage is smaller by a significant factor as you don't need to store the key names as well as the values
2) unless you know that your app is going to generate huge amounts of data (like millions of rows of a day) I would not worry about scalability at start up as most databases will scale to a fairly considerable level. More relevant might be the ability to replicate and co-locate the database in multiple regions or quicky scale up the available compute if you have temporary spikes (e.g. release date for Taylor Swift tickets) . Even when it does generate huge amounts of data, there are techniques you can employ to write data quickly into document storage and then process it into relational storage later.
1) All data is relational, that's what makes it data. The question is really about whether you need to store it in different tables with a relational key (order header, order lines with a common order ID) or in a nested structure
{orderID: 1,
customerID:9876,
orderdate:2023-11-09,
lines: [
{
lineNumber:1,
itemcode:ABC123
},
{
lineNumber:2,
itemcode:DEF456
}
]
}
The order document above makes noSQL database reads very fast across the order, but if you want to aggregate data about items you have to scan the entire order collection or save the data in multiple formats. With the data in a RDBMS (SQL database) it is much easier to navigate in any direction (e.g. by customer, item, item type, geography or timeslice) the reads are more complicated to craft but data storage is smaller by a significant factor as you don't need to store the key names as well as the values
2) unless you know that your app is going to generate huge amounts of data (like millions of rows of a day) I would not worry about scalability at start up as most databases will scale to a fairly considerable level. More relevant might be the ability to replicate and co-locate the database in multiple regions or quicky scale up the available compute if you have temporary spikes (e.g. release date for Taylor Swift tickets) . Even when it does generate huge amounts of data, there are techniques you can employ to write data quickly into document storage and then process it into relational storage later.
Thank you for noting that