Prisma'nın en güçlü yanı şema dosyasının okunabilirliği, ama bu okunabilirlik bazen veritabanı tasarımındaki gerçek karmaşıklığı gizleyebiliyor. BalkoLüx'te ürün, kategori, varyant ve stok ilişkilerini modellerken bu tuzağa birkaç kez düştüm.
Ürün varyantlarını (renk, boyut gibi) ayrı bir tabloya çıkarmak yerine ürün modeline JSON alan olarak eklemek başlangıçta daha hızlı görünüyordu; ama stok azaldıkça varyant bazlı filtreleme ve raporlama sorguları JSON içinde arama yapmaya zorlanınca performans hızla bozuldu. Çözüm, ProductVariant'ı ayrı bir tablo yapıp her varyant kombinasyonu için kendi stok satırını tutmaktı; sorgu karmaşıklığı arttı ama index'lenebilir, ölçeklenebilir hale geldi.
N+1 sorgu problemi Prisma'da include kullanırken bile sinsice ortaya çıkabiliyor; özellikle iç içe geçmiş include'larda. select ile yalnızca gerçekten gereken alanları çekmek ve gerektiğinde Prisma'nın findMany'sindeki take/skip yerine cursor tabanlı sayfalamaya geçmek, büyük ürün listelerinde sorgu sürelerini gözle görülür şekilde kısalttı.
Migration disiplini de hafife alınmaması gereken bir konu: production'a giden her migration'ı önce boş bir staging veritabanında geri alınabilirliğini test ederek uyguluyorum. Bir foreign key kısıtlamasını yanlış sırada eklemenin canlı ortamda nasıl bir kesintiye yol açabileceğini bir kere yaşadıktan sonra bu adımı asla atlamıyorum.
Şema tasarımı, ORM'in size sağladığı kolaylığa rağmen, hâlâ ilişkisel veritabanı temelleri üzerine kurulu bir disiplin.
{ }