You are viewing a single comment's thread from:

RE: [STEEMSQL.COM] A public SQL server database with all Steemit blockchain data

in #steemit8 years ago

the differences between the graph database and the monolithinc, intransient relational database takes some compilation of data, and new blocks alter records, in ways that can be difficult to adapt, such as if a poster makes a really big edit, and suddenly the datatype has been overflowed.

But I think this is a cool idea. It might make a model for moving from a memory heavy graphene database to a storage heavy sql, maybe some sort of hybrid to cache data for faster retrieval or so.

Sort:  

SteemSQL database is a replica of the whole blockchain, not a compilation!
This mean if a user edit a post, you will find 2 or more transactions in TxComments with the same author/permlink but with different bodies/titles.
Compilation of data is made at query time.

Ah. So it's just another implementation of the graph database protocol, layered on top of a relational database.

This isn't a graph database at all, unless I am somehow mistaken.

No, it however has to implement one to allow the diff-updates that the platform allows, which essentially is a graph database (like CVS or Git). It just gives you the ability to search using SQL queries which are very concise and neat and easy to write, and with that pull all kinds of higher level data out of it. I think that was the purpose of building it - to allow more people to tinker with analytics.

Seriously, Doesn't this defeat the purpose of decentralization?

Why its defeat decentralization?

No. The essence of data analysis is collecting (aggregating ) data and making meaningful insights from it, which requires centralization by rule. The decentralized nature of the data isn't in jeopardy here because there are still unlimited copies of the Steemit blockchain out there ensuring that there is no vulnerable, mutable, single-source of the truth. This particular copy just happens to facilitate reporting.