A few Palantir Ontology Anti-Patterns (Don’t do this)

In the spirit of the Postgres “Don’t Do This” guide (https://wiki.postgresql.org/wiki/Don’t_Do_This), documenting anti-patterns can be just as valuable as documenting best practices. It is also an exercise in unlearning. Using the ontology well often requires unlearning database-first thinking. This is synthesized mainly from https://community.palantir.com/t/ontology-and-pipeline-design-principles/5481

The ontology is not your ERP database. The ontology is the semantic system of record that defines the canonical objects, relationships, and business meaning that connect systems together. As Áron Székely recommends “Do not just take whatever dataset is in your source system and sync it to the Ontology.”
You may have this code smell if:
• An Object Type is a direct copy of a source table
• You are modeling every column because it exists, not because it drives decisions
• Object and property names reflect database schema instead of business language
• The ontology is easier for a DBA to understand than an operator or analyst
The id (primary key) column must be of type string. (This makes the DBA in me <shudder> )
You may have this code smell if:
• The primary key is an integer
All Object Types must have a separate Primary Key column named id

What Anti-Patterns have you seen?

Michael Ellerbeck