As you already know, in our ORM, high-level types like dynamic
arrays or TPersistent / TCollection properties
are perfectly handled, and stored as BLOB or TEXT inside the main data
row.
There is no external linked table, no Master/Detail to maintain. In
fact, each TSQLRecord instance content could be made
self-contained in our ORM.
Of course, you have the choice to implement the data in the class master/detail scheme. You have direct OOP implementation of one-to-one, one-to-many, or many-to-many relationship.
But when the server starts to have an increasing number of clients, such a "shared nothing" data layout could be a major benefit. In fact, the so-called sharding, or horizontal partitioning of data, is a proven solution for web-scale databases, such as those in use by social networking sites. How does eBay or Facebook scale with so many users? Just by sharding.
A simple but very efficient sharding mechanism could therefore be implemented with our ORM. In-memory databases, or our BigTable component are good candidate for light speed data process. Even SQLite could scale very well in some cases.
Storing detailed data in BLOB or in TEXT as JSON could first sounds a wrong idea. It does break one widely accepted principle of the RDBMS architecture. But even Google had to break this dogma. And when MySQL or such tries to implement sharding, it does need a lot of effort. Others, like the NoSQL MongoDB, are better candidates: they are not tight to the SQL flat scheme.
Therefore, on second thought, having at hand a shared nothing architecture
could be a great advantage. Our ORM is already ready to break the
table-oriented scheme of SQL.
Probably another benefit of the RESTful approach!
Just my Sunday's evening thoughts...
Any
feedback?
