Konuyu Açan
#1
Bir SQL API’sinde sorunlar çoğu zaman sorgu yazımından değil, veritabanı şemasının API’nin kullanım biçimiyle uyuşmamasından çıkar. Örneğin sipariş ve sipariş kalemlerini tek tabloda tutmak ilk aşamada kolay görünür; ancak ürün, fiyat ve miktar bilgileri tekrarlandıkça güncelleme tutarsızlıkları ve gereksiz veri büyümesi başlar. İlişkileri doğru modellemek, API katmanının da daha öngörülebilir davranmasını sağlar.
Önce temel varlıkları ve aralarındaki ilişkileri belirlemek gerekir. Birincil anahtarlar kayıtları kararlı biçimde tanımlar; yabancı anahtarlar ise geçersiz ilişkileri engeller. E-posta gibi benzersiz olması gereken alanlarda veritabanı düzeyinde UNIQUE kısıtı kullanmak, yalnızca uygulama kodundaki kontrole güvenmekten daha sağlamdır. Aynı şekilde NOT NULL ve CHECK kısıtları, hatalı verinin sisteme girmesini sınırlar.
API’nin okuma ve yazma desenleri de tasarımı etkiler. Sık filtrelenen veya ilişkilendirme yapılan sütunlarda indeksler yararlı olabilir; fakat her indeksi eklemek yazma işlemlerini ve depolama maliyetini artırır. İndeks kararı, gerçek sorgular ve yürütme planları üzerinden verilmelidir. Birden fazla tabloyu değiştiren işlemde transaction kullanmak, kısmi güncellemelerin önüne geçer. Şema değişikliklerini sürümlü migration’larla yönetmek de dağıtımlar sırasında API ile veritabanının uyumunu korur.
Siz API projelerinde şemayı önce iş kurallarına göre mi, yoksa beklenen sorgu yüküne göre mi şekillendiriyorsunuz?
Önce temel varlıkları ve aralarındaki ilişkileri belirlemek gerekir. Birincil anahtarlar kayıtları kararlı biçimde tanımlar; yabancı anahtarlar ise geçersiz ilişkileri engeller. E-posta gibi benzersiz olması gereken alanlarda veritabanı düzeyinde UNIQUE kısıtı kullanmak, yalnızca uygulama kodundaki kontrole güvenmekten daha sağlamdır. Aynı şekilde NOT NULL ve CHECK kısıtları, hatalı verinin sisteme girmesini sınırlar.
API’nin okuma ve yazma desenleri de tasarımı etkiler. Sık filtrelenen veya ilişkilendirme yapılan sütunlarda indeksler yararlı olabilir; fakat her indeksi eklemek yazma işlemlerini ve depolama maliyetini artırır. İndeks kararı, gerçek sorgular ve yürütme planları üzerinden verilmelidir. Birden fazla tabloyu değiştiren işlemde transaction kullanmak, kısmi güncellemelerin önüne geçer. Şema değişikliklerini sürümlü migration’larla yönetmek de dağıtımlar sırasında API ile veritabanının uyumunu korur.
Siz API projelerinde şemayı önce iş kurallarına göre mi, yoksa beklenen sorgu yüküne göre mi şekillendiriyorsunuz?
