Database – Android Card Game Database for Deck Building

Using rest to send/receive data to/from the server is a fine choice, its a well known and stable protocol for client-server communication. However, you're going to need a system to push updates (or notifications) to the clients as they change on the server, and to do that you need something other than http web connections.

On an Android device, you're best off using push technology - Google has a few sites that talk about implementing this kind of thing. When you receive the notification, if it doesn't already contain the data, it can be used as a trigger for the app to retrieve the data using your usual methods (ie automatically click the 'refresh' button)

If you don't want to use the push systems, then the other answer is to open a persistent tcp/ip socket to the server while the players are actively playing and receive notifications and data directly through that.

I would go for the following UserSearches table:

UserId

Date

Then I add a column for each field

This way, you can easily SELECT the columns you want to consider, then group / sum the data.

A business case you may encounter : How many different user searched for a price over 20000:

SELECT count(UserId) 
FROM (SELECT UserId, SUM(price) 
      FROM UserSearches 
      WHERE price > 20000 
      GROUP BY price)

It seems pretty straightforward to me.

The count is not needed. You don't have an history if you don't have a Date associated to every search.

Your Field column is going to be problematic. Your table is supposed to make you store normalized data, not key-value pairs.

EDIT (to answer your comment)

If you add a field to your search, add a column, existing data will have NULL for this column. You loose a bit of info which is the 'context' of your search (what fields where available at the time). If it is relevant for you to keep the context of every search set the defaut value to "N/A" meaning "Not available at the time". It doesn't seem very clean (you might need to exclude the "N/A" value often) but it's flexible.