Truenumber tip: Language versus database

If you’ve ever bought a part at an auto-parts store, you know that the conversation goes like this: “I need a battery for my 2011 Jeep Grand-Cherokee”. “OK, what model?” “um…Laredo 4x4” “Engine?” “it’s a six”.

Next time you order, you might save time by saying “I need an alternator for my 6-cylinder 2011 Jeep Grand-Cherokee Laredo 4x4.”. That’s a mouthful. In truenumber terms, it’s human language confronting a parts-store database.

That long sentence is a kind of reading of the screen the clerk ends up with on the computer. The database has column names like “model” and “levelName” for Grand-Cherokee and Laredo, but when we speak, the sequence of adjectives is what narrows down the many connotations we have for a given word. “Laredo” is a city in Texas (also Missouri and Montana), but “Grand-Cherokee Laredo” is pretty certain to communicate what is meant.

Keeping this in mind is helpful when writing truenumbers. A database specifies a particular thing by defining a table with columns named to mean something to developers,. Humans refer to a particular thing by stringing together words into descriptive noun phrase, and truenumbers are made from such phrases.

The SQL query “SELECT * from carTable WHERE levelName=’Laredo’ and model=’Grand-Cherokee’” will pull up the car from a database. In Truenumbers, searching for sentences where the subject contains “Grand-Cherokee Laredo” will do the same thing, without requiring knowledge of any schema or SQL. Unlike a schema, you can feel free to add more detail to your phrases when needed, because data will be accessed by search, not by specifying fields. So feel free to add “new” or “used” to your car when needed. No new database column needed.