[simondedalus]

not only would it be hard, but using a blockchain (a type of database) to represent a functional SQL database using smart contracts is a mind-numbingly bad idea.

(insert "should i use a blockchain" infographic, which is amusingly impossible to google image search for, because this question evidently does not often occur to people...)

[misterdata]

That might just depend on what parts of a "SQL database" you'd implement using a blockchain, and on the application type. You could e.g. segregate the data and only use the blockchain to authorize or timestamp transactions, for instance. In the latter case, Blockchain is just another consensus layer, and all distributed databases need one. See also https://github.com/pixelspark/catena, which uses the blockchain like a replication journal, logging only mutating queries and providing authorization based on public key crypto (disclosure: I am the author).

[simondedalus]

not to put too fine a point of it, but there's a world of difference between creating a ledger that creates a "distributed" SQL database whose integrity is guaranteed among non-trusted nodes through a blockchain, and using smart contracts to "put a functioning SQL database on the blockchain."

"get used to blockchain when all you know is SQL" - cool.

"guarantee all us non-trusted nodes have the same SQL database" - ...sure, but for any project such that i want this, i'm pretty sure i don't need a blockchain. (but of course, your project doubtless has uses i haven't thought of)

"i want a trustless SQL database so i'm going to use EVM and solidity and put it on The Blockchain because i'm awesome" - very bad.

"i'm starting a new project, so naturally i need to use a blockchain" - extremely bad.

[ah-]

https://github.com/pixelspark/catena