4 ms·
To be even more pessimistic you could point out: 1. Read Committed is not that restrictive to be honest. If you're short on memory it can be an issue but even
by MSM 14y ago
To be even more pessimistic you could point out:
1. Read Committed is not that restrictive to be honest. If you're short on memory it can be an issue but even in a high frequency system it should only lock at the row level. Beyond that, why would you be pushing to read dirty data? That's an issue in and of itself.
8/9. Arrays? JSON? XML? It's not relational data. Either parse it or put it in a different system, no RDBMS is going to handle these very well because they break the 'Relational' part. They might be accomodated, but trying to work with them is not a good idea in the vast majority of cases. I'm promoting SQL here and I still have to point out that SQL handles XML like crap too, try and index an XML blob.
- josteink 14y ago> I'm promoting SQL here and I still have to point out that SQL handles XML like crap too, try and index an XML blob. To be fair SQL Server has constructs for this, but they are plenty in types and awful in nature. They are even worse to understand how they work and interact together and how they will optimize your queries. And I guess maybe that was your point? Handling XML in SQL was "reasonable" when the option was full fledged, tripple-verbose DOM code in compiled languages. These days though, you have better ways of "shredding" XML into usable data-constructs and the desire to do anything of that sort inside the DB is definitely approaching zero.