0

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!

Chris Dutrow
  • 48,402
  • 65
  • 188
  • 258

1 Answers1

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.

Peter Knego
  • 79,991
  • 11
  • 123
  • 154
  • Hey Peter, I keyed using a UUID because I try to make a habit of not keying against the data itself. Sometimes information that I think will be unique turns out not to be. In this case, I would have to key against the phone number and the extension, not just the phone number. And this could cause problems if someone wanted to make a phone number that was a main company line, then in the description: "Ask for Carol". It would also be annoying if someone typed in the number wrong and then corrected it, the item would have to be re-keyed. – Chris Dutrow Mar 12 '12 at 13:04