v6 - Performans Analizi

30K Veri için Sistem Karşılaştırması

Media, SEO, Favorite Pattern'leri ile v4/v5 Karşılaştırması

30 Aralık 2025

Basit Anlatım (Herkes İçin)

Sistemde 3 farklı pattern kullanılıyor. 30.000 playlist gelecek, hangisi daha hızlı?

Media Pattern

Fotoğraf/dosya yükleme sistemi. "Bu resim hangi ürüne ait?" sorusunu cevaplar.

SEO Pattern

Google için sayfa bilgileri. "Bu sayfanın SEO ayarları nerede?" sorusunu cevaplar.

Favorite Pattern

Kullanıcı favorileri. "Kim neleri favoriledi?" sorusunu cevaplar.

Mevcut Sistem Verileri

44
Playlist
71
Playlist-Sector
90
Playlist-Radio
9
Kurumsal

30.000 playlist gelecek, ortalama 3-5 kurumsal ilişki = ~100K-150K satır

Pattern Karşılaştırma

Pattern Tablo Yapısı Index Row Boyutu Kullanım
Media model_type + model_id Composite + 8 ek index ~500 byte One-to-Many (dosya)
SEO seoable_type + seoable_id Composite + status + score ~2KB One-to-One (SEO)
Favorite favoritable_type + favoritable_id + user_id Composite + Unique constraint ~300 byte Many-to-Many
v4 Pivot playlist_id + corporate_id PRIMARY composite + FK 16 byte Many-to-Many (direkt)
v5 Poly playlistable_type + playlistable_id Composite + playlist_id ~70 byte Many-to-Many (unified)

30K Veri Performans Projeksiyonu

Test Senaryosu

  • 30.000 playlist
  • 50 kurumsal hesap
  • Her playlist ortalama 3-5 kurumsal'a atanmış
  • Toplam ilişki: ~100.000-150.000 satır

v4: Pivot Tablo (ÖNERİLEN)

Index boyutu (100K satır): ~1.6 MB
Tablo boyutu: ~1.6 MB
Query tipi: Integer-to-Integer JOIN
Beklenen hız: <1ms
SELECT p.* FROM playlists p
JOIN playlist_corporate pc
  ON p.id = pc.playlist_id
WHERE pc.corporate_id = 5

v5: Polymorphic Unified

Index boyutu (100K satır): ~7 MB
Tablo boyutu: ~7 MB
Query tipi: VARCHAR + Integer JOIN
Beklenen hız: 1-3ms
SELECT p.* FROM playlists p
JOIN playlistables pl
  ON p.id = pl.playlist_id
WHERE pl.playlistable_type = 'corporate'
  AND pl.playlistable_id = 5

Neden v4 (Pivot Tablo) Öneriliyor?

Performans Avantajları

  • 4x daha küçük index - Daha hızlı arama
  • Integer-only JOIN - VARCHAR karşılaştırması yok
  • Composite PK - Otomatik unique + index
  • Memory-efficient - 16 byte vs 70 byte/satır

Uyumluluk Avantajları

  • Mevcut pattern - playlist_sector, playlist_radio ile aynı
  • Test edilmiş - 161 satır sorunsuz çalışıyor
  • Basit Laravel - belongsToMany hazır
  • Kolay debug - Tablo adı açık: playlist_corporate

v5 (Polymorphic) Ne Zaman Mantıklı?

v5 İyi Seçim Olur Eğer:

  • 10+ farklı entity tipi olacaksa (sector, radio, corporate, artist, label, genre, mood...)
  • Sürekli yeni tipler eklenecekse
  • Tek bir yerden tüm ilişkileri yönetmek istiyorsanız

v5 Gereksiz Eğer:

  • Sadece 3-4 entity tipi varsa (sector, radio, corporate)
  • Performans kritikse (streaming, realtime)
  • Mevcut pattern zaten çalışıyorsa

Media/SEO Pattern'i Bu İşe Uyar mı?

Media Pattern - UYGUN DEĞİL

Media pattern ONE-TO-MANY ilişki içindir. Bir media bir modele aittir.

  • Bu sistemde playlist MANY corporates'a ait
  • Media'da collection_name var - burada gereksiz
  • Media tablosu çok field'li (~500 byte/satır)

SEO Pattern - KISMEN UYGUN

SEO pattern ONE-TO-ONE ilişki içindir. Bir sayfa bir SEO kaydına sahip.

  • Bu sistemde playlist MANY corporates'a bağlanacak
  • morphs() kullanılabilir ama v5'ten farkı yok
  • Ters yönde: seoable (model → seo), bizde playlist → corporate

Sonuç

Media ve SEO pattern'leri farklı ilişki tipleri için tasarlanmış. Playlist-Corporate MANY-TO-MANY ilişkisi için en uygun pattern:

  • v4 (Dedicated Pivot) - Performans kritik, mevcut pattern
  • v5 (Polymorphic) - Esneklik kritik, çok entity tipi

Final Öneri: v4 (Pivot Tablo)

<1ms
Query Hızı
1.6MB
100K Satır Boyutu
0
Mevcut Kod Değişikliği

Uygulama Planı:

  1. 1 Migration: muzibu_playlist_corporate tablosu oluştur (playlist_sector pattern'i)
  2. 2 Model: Playlist'e corporates() ilişkisi ekle
  3. 3 Model: MuzibuCorporateAccount'a playlists() ilişkisi ekle
  4. 4 UI: Playlist sayfasına "Kurumsal" filtresi ekle (sector/radio gibi)