Veezoo

Module 3 · Lecture 3.4

Properties

name_sql, synonym_sql and description_sql enrich entities automatically, plus the class-or-string test.

A freshly synced Customer class can look useless: every entity is labelled with a cryptic database ID, while the actual names sit in a second class of their own. Both columns describe the same business concept, so this lecture merges them into one class using properties.

Three properties enrich entities automatically at sync time: name_sql for the label, synonym_sql for extra ways to refer to an entity, and description_sql for a description. The lecture closes with the modelling decision that comes up constantly: class or string?

Key points

  • One concept, one class: an ID column and a name column are two aspects of the same concept, so they belong in one class, not two.
  • name_sql: the sql tag keeps holding the stable ID and name_sql points at the column with the display name, so entities sync with real names on top of stable IDs.
  • synonym_sql: generates synonyms for every entity from a column, for example the ID itself, so users can refer to a customer by name or by ID.
  • description_sql: fills each entity's description from a column the same way.
  • Class or string: there is no always-correct answer, it depends on how users interact with the attribute. If they name the value in a question ("from the West") it is a class, and if they only display it or search within it ("reviews containing football") it is a string.

Check your understanding

Customer entities are labelled with cryptic IDs, and the real names sit in a separate Customer Name class. What is the right fix?

Users sometimes paste a customer's ID into the chat instead of the name. How do you make the ID matchable without giving up the readable names?

A "segment" column holds three repeating values and a "comments" column holds free-text feedback. How are the two modelled?