A key component of any database is the lookup table and the Foreign Key. From countries and states, to statuses, and colors, the standard lookup table provides a known set of options for combo boxes. The proper term is "domain relation" that provides a limited set, or a domain, of possible correct items for an attribute.
Relational database modelers even argue about whether a system with many domain lookup tables should have a table for each lookup list, or if the multiple lookup lists should be merged in to one massive lookup table. There are pros and cons to each pattern, and my goal here is not to weigh into that debate but to illustrate how critical lookup tables can be,
In a pure graph database, rows can only be represented in nodes. Every domain lookup item would be a node and the Domain lookups FK relationships would be relationships, or connections to the domain node.
TejonDB is a hybrid database so we can pull the best features of each type of database and avoid the limitations that cause problems. Lookup lists are built in TejonDB by creating and populating Domain Classes. This keeps the first class, or main, objects in the object classes, and keeps the lookup items from appearing as nodes. Attributes with the Lookup data type can then point to the domain classes, which in effect creates a foreign key form the attribute to the domain class. The TejonDB application automatically reads the meta-data about the attribute and the domain class can creates a combo box with a drop down list.
And that's how lookup tables work in TejonDB.