Joe ObbishJoe Obbish
James JenkinsJames Jenkins
Top Answer: > Is blockchain a **potentially viable database** solution for modern, **high transaction volume** applications?
Answer #2: I'm very familiar with cryptocurrency and databases, and I can tell you it's not a great DB engine at all.
Answer #3: In 2014 we built ascribe.io with the premise of using Bitcoin as a database for Intellectual Property claims. Upon release, we plugged the network because it couldn't handle the throughput, latency was at least 10 minutes and we were limited by what we could put into the OP_RETURN, forcing us to store the actual digital file relating to the claim in Amazon S3. We realized that Bitcoin in its current form could never be a high transaction database.
Jack DouglasJack Douglas
Erik DarlingErik Darling
Joe ObbishJoe Obbish
Top Answer: Excellent question. As far as I am aware of, under those conditions (i.e. guaranteed no `NULL`s and no need for the extra functionality) there shouldn't be any specific concerns. This could be a situation similar to `CURSOR`s where, if a generic rule is needed, it would be: "don't use cursors". But, the actual rule is: "only use cursors when/where appropriate". The problem is educating people on the technical details of cursors such that they can make that decision, which is those of us who know enough about such things ignore the generic rule and proceed to use them appropriately.
Top Answer: see [this answer on "Optimizer not choosing index union plan"](/databases?q=813#a958)
Answer #2: Rather than focusing on how to improve a query like this, which is what the other answers are doing, I'm going to try to answer the question being asked: *why* doesn't the optimizer produce a plan like the one you've described (that scans the Users table, and then seeks into the two indexes on the Comments table).
Answer #3: When you have a join, the Query Optimizer will consider how best to satisfy the predicates involved with the various join techniques. It doesn’t try to re-evaluate the query as if had been written with APPLY, which is what you kinda want here, where it would see the right hand side of the join as like a sub-query.