Should I drive a stats list from a database view

I am working on a game that shows user stats: enemies killed, time in game, etc. It is an ordered list of results, driven from an sqlite db.

I'm struggling with a design choice for how to show the stats to the user. The problem is best expressed by example. Take the following:

-= Personal Bests =-
Most coins collected: 15
Most enemies killed: 26
Favourite Weapon: Laser
Most often Killed By: Badguy

The above table is a simple structure of two columns: Label, and Value. However, each row has a different data structure to it. The query to support each row above requires different aggregations and filters (on the same table).

My question is about the best way to put this view together.

Strategy 1: Brute Force (App-Side) I call 4 queries to my db for each row, each specific to the stat. This will allow me max flexibility between app versions, since all the logic to support the view would be in the app. It is also helpful for when no rows are returned for the given stat, allowing me to easily plug in a default value. Also, it allows me to better handle the various datatypes returned for the given stat.

Strategy 2: Custom View (DB-Side) I call 1 query to my db on a view, and allow it to drive the list. The view would be 4 queries UNION'd together. In my app, I would simply grab the header and the value, and put them into the table. Upside is, I can change the stat screen on the fly for all app versions without a new build. Downside is complexity around defining my view, and handling cases when there are no rows returned for a given sub-query.

Performance is not a huge concern since I will have max 20 rows of stats. I think I am mostly concerned with writing sustainable code / time-efficient code that will not cause me a huge headache down the road.

I started with the DB View, but I'm already getting annoyed with that, so I'm thinking of switching to Strategy 1. Just wondering what the community thinks.