Recognises a foreign-key cycle taken as resolved
The header note saying all tables are created first and every foreign key added afterwards as ALTER TABLE. The script runs; the design does not. Two tables each mandatory to the other cannot be loaded without deferring a constraint, and not every engine can defer one.
Can AI do this?
Not tested yet
No AI benchmark covers this knobit yet. New results are announced in the Can AI Do the Job? newsletter.
What it looks like in practice
Expected result: The cycle and the load order or deferral it needs
How it is assessed: Flags the deficient case and passes the acceptable one. Deficient: dim_account.primary_card_key → dim_card and dim_card.account_key → dim_account, both NOT NULL; the DDL deploys and the first load has no row it can insert first Acceptable: One direction made optional, or the "primary card" relationship moved into its own table. The cycle is resolved in the logical model, not worked around in the load (the header note is a prompt, not a solution)
Also known as: Foreign-key cycle fallback treated as resolved (generated DDL)
Related knobits
Builds on
All 33 knobits of Generate and review DDL.
Source: Review checklist 08-ddl, row 14; ISO 9075; this skill (08-ddl.md)