i have seen examples discourse tables in relational database don't have foreign keys. while other tenants of rdb still used constraints, indexes , fulltextsearch etc.. per rails active record guidelines , foreign keys dropped.
https://meta.discourse.org/t/foreign-key-constraints-in-db/2642
do need periodically check consistency in such applications ? , in case should done each request -response there no invalid foreign key , correct @ same time in application layer.
ok first thing understand why put such constraints in database. second point why people don't this. third ramifications of not doing are.
why put ri checks in database
a relational database big math engine performing set (well, bag, due concessions real-world data integrity problems) operations on large sets of data. sets grow, ability verify integrity of data reduces until @ point 1 has trouble verifying entire validity of data according set model 1 follows. have worked postgresql databases constraints not possible, in areas had accept there referential integrity violations.
the problem of managing referential integrity 1 software project owns database can formidable, can become far worse when many different programs can read or write same data. gets worse because normalization , encapsulation concerns increase number of pathways reading (and worse, writing) data.
ensuring 1 can make sure referential integrity not violated on each write important tool in data management.
why people avoid ri checks in database
referential integrity constraints not free. there 2 important drawbacks using them cause developers decide not to.
- referential integrity checks not free. impact database performance, , database understood least scalable part of system, and
- they divide logic, placing in different locations , segregating data model logic application logic. while separation of concerns desirable, single application owns database, (but not always!) considered less desirable tradeoff.
it worth noting further rails guidelines don't offer solid guidance on tradeoff. many orms, active record offers tools addressing in application, found plenty of examples of people using foreign keys in database, , nobody saying "don't use them."
concerns avoiding ri checks in database
the concerns , further mitigating measures of course depend on importanc , further use of data. lower-impact data set private data store of application (the normal rails way) doesn't have same implications higher-impact data store used intended used decision support later. repeated read-use important question in deciding whether need periodically re-scan.
the second concern alternate sources of writes. in general in model important concern prevent alternate sources of writes, outside of uses of these specific activerecord-using classes.
so in answer question, may or may not need to. should risk assessment , decide do. such risk assessment guide decision not @ moment in future.
as side note
you can use foreign keys insist on consistency while using hooks , forth ensure logic handled in activerecord component. i.e. instead of using on delete cascade have handled hook.
