Question

I’m using Google App Engine and thus Big Table.

I have a person entity that looks like this:

{
    // This property would be encoded into JSON and saved un-indexed as db.Text()
    phone_numbers:
    {
        'hHklams8akjJkaJSL': // <-- Should I key this object?
        {
            number:'555-555-5555',
            type:'mobile', 
        },
        etc...
    },
    // This property is an array of strings.  
    // It is searchable so that a query could be run to find all 
    //   people with a particular phone number: 
    //   "SELECT * FROM person WHERE phone_number_search_property =      
    //     '5555555555'"
    phone_number_search_property:['5555555555','other phone numbers...'],

    first_name:'...',
    etc...
}

The phone_number property is stored as a blob of unindexed text in JSON format (db.Text). If I want to refer to a particular phone number in this situation, I decode the json, then get the phone number with the particular key that I am looking for.

The phone_number_search_property is used for searching. It enables a search by phone number: "SELECT * FROM person WHERE phone_number_search_property = '5555555555'"

What is a good way to refer to a phone number inside of an entity in this situation? Here, I have each value keyed using a UUID. Is this a “normal” and accepted way of doing things? If not, what is?

Thanks!

Answer 1

1. If data object is really just part of another object and is never accessed without the “parent” object (as is the case with phone number and person) then IMHO it’s ok to serialize it and store it inside the “parent” object. So what you did is OK.

2. You search persons by phone number, so the solution to have additional property with (normalized) phone numbers is working. If you’d need to search on additional property, then it would not work (e.g. limiting search to only mobile numbers).

3. Why do you key serialized phone numbers by a hashed string (I assume you generate it via UUID.fromString(String))? Just use the (normalized) phone number – it is unique.