To make things more confusing, Brembo doesn't actually make a lot of the brake calipers on factory cars. They simply charge the manufacturer to license the Brembo brand and stamp that on a brand X caliper. A bit like Donald Trump these days.
I can see some logic with the developers having some liability when grossly negligent.
The problem is that this will likely have very limited impact on the number of bugs and software quality. It will however increase costs and we will end up with ridiculous class action law suits that primarily benefit the lawyers.
The real question is *what* you are doing with relational databases and what are you trying to accomplish. There is rarely a magic new buzzword or hip new thing that magically solves all your problems.
Are you doing important financial calculations, or anything that requires ACID? If the answer is yes, then you may want to investigate sharding and figure out ways to safely split your data amongst multiple databases while still insuring that you can do a transaction on one system for important situations.
If you are serving up read heavy web content that doesn't need any fancy transactions or specific versions you can easily set up an intermediary cache with something like memcache, or with many of the NoSQL storage systems available (which typically act like memcache with disk backing and persistence). This might mean that you have your primary source in a SQL database or perhaps just the portions that require ACID and then you periodically sync changes from your SQL to memcache or your NoSQL system.
If you are doing lots of writes you may want to consider a system of local storage per node, whether it be SQL, NoSQL or something else and then aggregate and synchronize that at a later point for reporting or some sort of centralized usage.
SQL and NoSQL are just tools, not a religious philosophy. If you need to screw in a screw, don't use a hammer. The same goes for using or not using a relational database, I find that most business need a relational database somewhere in their technology stack, this is because businesses ultimately deal with things that relate to making money... and dealing with money properly often requires ACID features and transactions.
Lastly, remember that disks are slow and memory is fast... sounds silly but people seem to forget where their data is coming from and bottleneck the disk on just about any web application that is slow.
Slashdot Mirror
To make things more confusing, Brembo doesn't actually make a lot of the brake calipers on factory cars. They simply charge the manufacturer to license the Brembo brand and stamp that on a brand X caliper. A bit like Donald Trump these days.
I can see some logic with the developers having some liability when grossly negligent.
The problem is that this will likely have very limited impact on the number of bugs and software quality. It will however increase costs and we will end up with ridiculous class action law suits that primarily benefit the lawyers.
The real question is *what* you are doing with relational databases and what are you trying to accomplish. There is rarely a magic new buzzword or hip new thing that magically solves all your problems.
Are you doing important financial calculations, or anything that requires ACID? If the answer is yes, then you may want to investigate sharding and figure out ways to safely split your data amongst multiple databases while still insuring that you can do a transaction on one system for important situations.
If you are serving up read heavy web content that doesn't need any fancy transactions or specific versions you can easily set up an intermediary cache with something like memcache, or with many of the NoSQL storage systems available (which typically act like memcache with disk backing and persistence). This might mean that you have your primary source in a SQL database or perhaps just the portions that require ACID and then you periodically sync changes from your SQL to memcache or your NoSQL system.
If you are doing lots of writes you may want to consider a system of local storage per node, whether it be SQL, NoSQL or something else and then aggregate and synchronize that at a later point for reporting or some sort of centralized usage.
SQL and NoSQL are just tools, not a religious philosophy. If you need to screw in a screw, don't use a hammer. The same goes for using or not using a relational database, I find that most business need a relational database somewhere in their technology stack, this is because businesses ultimately deal with things that relate to making money... and dealing with money properly often requires ACID features and transactions.
Lastly, remember that disks are slow and memory is fast... sounds silly but people seem to forget where their data is coming from and bottleneck the disk on just about any web application that is slow.