Like I wrote in the [previous post](/@felixxx/a-hacky-guide-to-hive-part-15):

>This is approach isn't the best for all applications; If you want to do historical stuff, analyzing large amounts of data, statistics and such things, HiveSQL is better.

It depends, on what you are trying to do...

> You might try to view these things as _get_ and _set_ methods; If you don't need to broadcast any other transactions than your own, you could even get away with treating it that way.

For this guide, I won't use HiveSQL, no.
You _could_ use this guide to build _your own, custom_ HiveSQL, though...

Hope that helps.