v7 - Gelecek Uyumlu Karar

Mood + Diğer Entity'ler Gelecekse

Ölçeklenebilirlik vs Performans Trade-off Analizi

30 Aralık 2025

Yeni Bilgi: Sistem Geliştirilecek

Kullanıcı belirtti: "İleride mood falan da gelecek, sistem geliştirilecek"

Bu durumda sadece corporate değil, birden fazla entity tipi playlist'lere bağlanacak.

Mevcut ve Planlanan Entity'ler

Mevcut (Çalışan)

Sector
playlist_sector (71 satır)
Radio
playlist_radio (90 satır)

Gelecek (Planlanan)

Corporate
Kurumsal hesaplar
Mood
Ruh hali kategorileri
Genre? Artist? Label?
Potansiyel gelecek entity'ler

Toplam Entity Sayısı: 2 mevcut + 2 kesin + 3 potansiyel = 5-7 entity

Kritik Karar Noktası

v4 Yolu: Her Entity İçin Ayrı Tablo

├── playlist_sector
├── playlist_radio
├── playlist_corporate
├── playlist_mood
├── playlist_genre?
├── playlist_artist?
└── playlist_label?
En hızlı query performansı
Her entity için migration gerekli
7 ayrı tablo yönetimi
Her entity için ayrı relation

v5 Yolu: Tek Unified Tablo

└── playlistables
    ├── playlist_id
    ├── playlistable_type (sector, radio, corporate, mood...)
    └── playlistable_id
Yeni entity = Sadece model değişikliği
Tek tablo, tek migration
Tek relation: morphedByMany()
~3x daha yavaş (hala <5ms)

Performans Karşılaştırması (30K Playlist, 5 Entity)

Metrik v4 (5 Ayrı Tablo) v5 (Unified) Fark
Toplam Tablo Sayısı 5 tablo 1 tablo v5 daha az
Yeni Entity Ekleme Migration + Model + Relation Sadece Model update v5 daha kolay
Query Hızı (tek entity) <1ms 1-3ms v4 daha hızlı
Tüm Entity'leri Çekme 5 ayrı query 1 query v5 daha az query
Disk Alanı (500K satır) ~8 MB ~35 MB v4 daha küçük
Kod Karmaşıklığı 5 relation metodu 1 morphedByMany v5 daha basit

Hibrit Yaklaşım: Mevcut + Yeni

Strateji

  1. 1 Mevcut tablolar kalsın: playlist_sector, playlist_radio (çalışıyor, risk yok)
  2. 2 Yeni entity'ler için: playlistables (polymorphic) tablosu kullan
  3. 3 İleride migrate: İstenirse sector/radio da polymorphic'e taşınır

Avantajlar

  • Mevcut sistem bozulmaz
  • Yeni entity'ler kolay eklenir
  • Kademeli geçiş mümkün

Dezavantajlar

  • İki farklı pattern
  • Kod tutarsızlığı
  • Query birleştirme zor

Güncellenmiş Öneri: v5 (Polymorphic Unified)

5+ entity tipi gelecekse, polymorphic yaklaşım daha mantıklı.

1
Tablo
∞
Entity Tipi
<5ms
Query Hızı

v5 Uygulama Planı:

  1. 1 Migration: playlistables tablosu oluştur
  2. 2 Morph Map: Boot'ta kısa alias tanımla (sector, radio, corporate, mood)
  3. 3 Trait: HasPlaylistDistribution trait oluştur (tüm entity'ler için)
  4. 4 Model: Playlist'e morphedByMany ilişkileri ekle
  5. 5 Migrate Data: Mevcut sector/radio verilerini taşı (opsiyonel)

Karar İçin Soru

Mevcut sector/radio tablolarını da polymorphic'e taşıyalım mı?

Evet - Tam Birleştirme

Tüm entity'ler tek tabloda, tutarlı kod

Hayır - Sadece Yeniler

Mevcut tablolar kalsın, risk az