क्या आपको सचमुच foreign keys की ज़रूरत है?

मूल लेख ↗ Hacker News चर्चा ↗

Relational databases में foreign key constraints लागू करने का सवाल data integrity और long-term maintainability को write performance, sharding flexibility, और migration complexity के खिलाफ खड़ा करता है। कई engineers का तर्क है कि constraints default होने चाहिए क्योंकि वे subtle bugs को रोकते हैं, data model का दस्तावेज़ीकरण करते हैं, और ऐसे data की रक्षा करते हैं जो किसी एक application से कहीं अधिक समय तक जीवित रहेगा; जबकि अन्य लोग बड़े MySQL deployments और specialized architectures की ओर इशारा करते हैं जहाँ constraints हटाकर integrity application code में enforce की जाती है। इस चर्चा से यह सामने आता है कि सामान्य scale पर foreign keys शायद ही bottleneck होते हैं, और उन्हें सुरक्षित रूप से छोड़ने के लिए उच्च अनुशासन, मज़बूत tooling, और trade-offs की स्पष्ट समझ चाहिए।

Foreign key constraints पर समग्र रुख

  • प्रबल बहुमत की राय: किसी भी non-trivial, लंबे समय तक चलने वाले सिस्टम के लिए by default foreign key (FK) constraints का उपयोग करें।
  • ये corrupt/orphaned data को रोकते हैं, ऐप की bugs को जल्दी उजागर करते हैं, और refactoring को अधिक सुरक्षित बनाते हैं।
  • बड़े legacy MySQL / multi-hundred-table systems के कई उदाहरण हैं जहाँ FKs नहीं थे और वे “data rot” के दुःस्वप्न बन गए, जिनके लिए brittle cleanup scripts और institutional knowledge की ज़रूरत पड़ी।

Data integrity, safety, और documentation

  • FKs को types, seatbelts, या protected memory की तरह प्रस्तुत किया गया है: इनके बिना भी code लिखा जा सकता है, लेकिन ये बहुत-सी गलतियों को कम लागत पर पकड़ लेते हैं।
  • मज़बूत constraints के साथ, टीमें यह मान सकती हैं कि “अगर यह DB में है, तो यह valid है,” और DB को एक fortress की तरह मान सकती हैं।
  • FKs data model के living documentation प्रदान करते हैं; missing FKs के कारण relationships समझना, या यहाँ तक कि यह पता लगाना कि कोई column reference है भी या नहीं, मुश्किल हो जाता है।

Performance, scale, और FKs हटाने पर कब विचार करें

  • आलोचकों का तर्क है कि FKs भारी write/delete workloads को धीमा करते हैं, sharding और online schema changes को जटिल बनाते हैं (खासकर MySQL में), और lock contention बढ़ाते हैं।
  • अन्य लोग जवाब देते हैं कि:
    • अधिकांश apps कभी उस scale तक नहीं पहुँचते जहाँ यह मायने रखे।
    • integrity की लागत कहीं न कहीं चुकानी ही पड़ती है; checks को application code में ले जाना उन्हें मुफ़्त नहीं बनाता और races का जोखिम पैदा करता है।
    • batch processing, deferred constraints, और tuning अक्सर performance समस्याओं को कम कर देते हैं।
  • कुछ बहुत high-scale या complex platforms native FKs के बजाय custom integrity layers लागू करते हैं, लेकिन इसे एक advanced, specialized विकल्प के रूप में प्रस्तुत किया गया है।

Application-level enforcement vs DB-level

  • एक पक्ष: integrity को app या service layer में enforce किया जा सकता है, खासकर अगर केवल one writer और strict access control हो; FKs optional हैं।
  • विरोधी पक्ष: multiple apps, ad-hoc access, और concurrency semantics DB guarantees को code में दोहराना fragile और error-prone बनाते हैं।

Soft deletes और deletion behavior

  • deleted_at soft deletes को FKs के साथ जोड़ना tricky है, खासकर यह सुनिश्चित करना कि active children वाले parents soft-delete न हो सकें।
  • सुझाए गए तरीके: universal soft-delete, is_deleted flag सहित composite FKs, deleted rows को अलग tables में ले जाना, या triggers के माध्यम से audit tables।

Environment strategies

  • कुछ लोग सुझाव देते हैं कि issues पकड़ने के लिए dev/test में ही FKs सक्षम रखें, जबकि ingestion speed के लिए prod में उन्हें disable कर दें।
  • इसे बहुत आलोचना मिली है, क्योंकि यह उल्टा और जोखिम भरा माना गया: असली data, जो वास्तव में मायने रखता है, production में होता है, test में नहीं।