Ana Tablo Yapıları ve EAV Mimarisinin Karşılaştırılması: Hangisini Tercih Etmelisiniz?

Verilerin yapısı, onu işleyen kod kadar önemlidir. – Martin Fowler

Önemli Noktalar

• Master Tables, güçlü bir yapı, doğrulama ve performans sunar.
• EAV (Entity-Attribute-Value), dinamik alanlar için esneklik sunar.
• Master Tables, sorgulama ve bakım açısından daha kolaydır.
• EAV, özniteliklerin sıklıkla değiştiği durumlarda faydalıdır.
• Çoğu kurumsal uygulama, saf EAV yerine karma bir yaklaşım kullanır.
• Yanlış mimari seçimi, uzun vadeli bakım sorunları yaratabilir.

İçindekiler

1. Giriş
2. Master Tables Nedir?
3. Master Tables’nın Avantajları
4. Master Tables’nın Dezavantajları
5. EAV Mimarisi Nedir?
6. EAV’nın Avantajları
7. EAV’nın Dezavantajları
8. Gerçek Dünya Örneği: Kolej Yönetim Sistemi
9. Performans Karşılaştırması
10. Ne Zaman Master Tables Kullanmalısınız?
11. Ne Zaman EAV Kullanmalısınız?
12. Karma Yaklaşım (Tavsiye Edilen)
13. Laravel Uygulama Stratejisi
14. İstatistikler
15. Sıkça Sorulan Sorular (SSS)
16. İlginç Gerçekler
17. Sonuç

Giriş

Bir yönetim paneli veya kurumsal uygulama oluştururken sıkça sorulan bir soru vardır:

Her modül için ayrı master tablolar mı oluşturmalıyım, yoksa maksimum esneklik için EAV (Entity-Attribute-Value) mimarisini mi kullanmalıyım?

Cevap, iş gereksinimlerinize, ölçeklenebilirlik hedeflerinize ve veri yapınızın ne sıklıkla değiştiğine bağlıdır. Her iki yaklaşımı da keşfedelim.

Master Tables Nedir?

Master Tables, geleneksel ilişkisel veritabanı tasarımına uyar.

Colleges Tablosu

colleges
---------
id
name
email
phone
city
state
website
type
funding
created_at
updated_at

Courses Tablosu

courses
---------
id
college_id
name
duration
fees
created_at
updated_at

Her alanın kendi sütunu vardır.

Master Tables’nın Avantajları

1. Daha İyi Performans
Veritabanları, sütun bazlı sorgulama için optimize edilmiştir.

SELECT *
FROM colleges
WHERE state = 'Gujarat';

Hızlı ve indeks dostudur.

2. Güçlü Doğrulama
Laravel doğrulaması basit hale gelir.

$request->validate([
   'name' => 'required',
   'email' => 'email',
   'phone' => 'required'
]);

3. Daha Kolay Raporlama
Rapor oluşturmak basittir.

SELECT state, COUNT(*)
FROM colleges
GROUP BY state;

4. Daha Kolay Bakım
Yeni geliştiriciler veritabanını hızlıca anlayabilir.

5. Daha İyi İlişkiler

college
   ↳ courses
   ↳ faculty
   ↳ students

İlişkiler net ve öngörülebilir kalır.

Master Tables’nın Dezavantajları

Şema Değişiklikleri
Diyelim ki bir müşteri aniden şu bilgileri ister:

NAAC Grade
NIRF Ranking
Accreditation Year

Şu adımı gerçekleştirmeniz gerekebilir:

ALTER TABLE colleges ADD COLUMN ...;

Sık değişiklikler zahmetli hale gelebilir.

EAV Mimarisi Nedir?

EAV, Entity → Attribute → Value anlamına gelir.

Öznitelikler sütunlar olarak değil, kayıtlar olarak saklanır.

Örnek

Entity
college
---------
id
name

Attributes
attributes
---------
id
name
1  NAAC Grade
2  NIRF Ranking
3  Accreditation Year

Values
entity_values
-------------
entity_id
attribute_id
value

1 | 1 | A++
1 | 2 | 15
1 | 3 | 2024

Artık yeni alanlar ekleyebilirsiniz; veri tabanı şemasını değiştirmeye gerek yoktur.

EAV’nın Avantajları

1. Dinamik Alanlar
Yönetici kullanıcılar alanları kendileri oluşturabilir.

Add Field
---------
Field Name: Campus Size
Type: Number

Hiçbir migration gerektirmez.

2. Form Oluşturucular İçin Mükemmel
Şu durumlarda faydalıdır:

• LMS
• ERP
• CRM
• Survey Sistemleri
• Dinamik Kayıt Formları

3. Sınırsız Özelleştirme
Her kurumun farklı alanları olabilir.

Örnek:

Organizasyon A:
NAAC Grade
NIRF Ranking

Organizasyon B:
Campus Size
Hostel Capacity
Aynı veri tabanı yapısı.

EAV’nın Dezavantajları

1. Karmaşık Sorgular
NIRF sıralaması 20’nin altında olan kolejleri bulmak.

SELECT ...
FROM entity_values
JOIN attributes ...

Geleneksel SQL’den çok daha zordur.

2. Kötü Raporlama Performansı
Toplamalar pahalı hale gelir.

COUNT()
AVG()
SUM()
GROUP BY()

Genellikle birden fazla join gerektirir.

3. Zor Doğrulama
Doğrulama kuralları dinamik hale gelir.

$field->type === 'number'
$field->type === 'date'
$field->type === 'email'

Daha fazla kod karmaşıklığı yaratır.

4. Daha Zor Hata Ayıklama
Veriler birden fazla tabloda yayılır.

SELECT * FROM colleges;

Tek bir kaydı anlamak için birçok join yapmanız gerekebilir.

Gerçek Dünya Örneği

Bir Kolej Yönetim Sistemi oluşturmayı hayal edin.
Master Tables Kullanarak

colleges
---------
name
email
phone
website
type
funding
city
state

Bilgiler bilindiyse iyi bir seçenek.

EAV Kullanarak

colleges

attributes

attribute_values
Kolejlerin özel alanlar oluşturabilmesi durumunda iyi bir seçenektir.

Performans Karşılaştırması

Ne Zaman Master Tables Kullanmalısınız?

Master Tables seçin:

• Veri yapısı stabil olduğunda
• Raporlar önemli olduğunda
• Performans önemli olduğunda
• İlişkiler iyi tanımlandığında
• ERP sistemlerinde
• LMS sistemlerinde
• E-ticaret platformlarında
• Mali uygulamalarda

Bu, çoğu iş uygulaması için tavsiye edilen yaklaşımdır.

Ne Zaman EAV Kullanmalısınız?

EAV seçin:

• Kullanıcılar özel alanlar oluşturduğunda
• Form yapısı sık değiştiğinde
• Farklı organizasyonlar farklı özniteliklere ihtiyaç duyduğunda
• Form oluşturucular inşa ederken
• Anket sistemlerinde
• CRM özel alanlarında
• Dinamizmi yüksek metadata sistemlerinde

Karma Yaklaşım (Tavsiye Edilen)

Kötü programcılar kod hakkında endişelenir. İyi programcılar veri yapıları ve ilişkileri hakkında endişelenir. – Linus Torvalds

Modern sistemlerin çoğu her ikisini de birleştirir.

Örnek:
Master Table

colleges
---------
id
name
email
phone
city
state

Özel Alanlar (EAV)

custom_fields
custom_field_values

Temel alanlar sütunlarda kalır.
Nadir kullanılan özel alanlar EAV’ye konur.
Bu, aşağıdaki avantajları sunar:

• Hızlı sorgular
• Kolay raporlama
• Dinamik özelleştirme (performans kaybı olmadan)

Laravel Uygulama Stratejisi

Pratik bir Laravel yapısı:

colleges
college_custom_fields
college_custom_field_values

Model isimleri:

College
CollegeCustomField
CollegeCustomFieldValue

EAV’yi yalnızca kullanıcı tanımlı alanlar için kullanın.
İşletme açısından kritik alanları normal sütunlarda tutun.

İstatistikler

1. Kurumsal ortamlarda en üst düzey veritabanlarının %90’ı ilişkisel veritabanlarıdır. Kaynak: DB-Engines Sıralaması
2. EAV, genellikle sağlık hizmetleri, CRM, e-ticaret ve öznitelikler sık sık değişen form oluşturucu sistemlerinde bulunur. Kaynak: NCBI EAV Araştırma Makalesi
3. Çoğu yüksek ölçekli iş uygulaması, saf EAV yerine karma bir yaklaşım kullanır. Kaynak: Martin Fowler Kurumsal Uygulama Mimarisi Kaynakları

Sıkça Sorulan Sorular (SSS)

1. EAV, geleneksel ilişkisel tablolar kadar hızlı mıdır?
Hayır, EAV genellikle sorgulama ve raporlama açısından daha yavaştır çünkü veriler birden fazla satır ve tabloda yayılır, bu da ek join ve dönüşümlere ihtiyaç duyar.

2. ERP sistemleri neden master tabloları tercih ediyor?
ERP sistemleri genellikle müşteri, sipariş, fatura ve ürün gibi yapılandırılmış iş verilerini işler. Master tablolar, daha iyi performans, daha kolay raporlama ve daha güçlü veri bütünlüğü sağlar.

3. EAV ne zaman tercih edilmelidir?
Kullanıcıların dinamik olarak özel alanlar oluşturması ve veri yapısının sık sık değişmesi gerektiğinde EAV tercih edilmelidir.

4. Laravel EAV mimarisini destekliyor mu?
Laravel, EAV’yi kutudan çıkar çıkmaz desteklemez, ancak CustomField ve CustomFieldValue gibi modellerin dinamik doğrulama kuralları ile uygulanması mümkündür.

5. Büyük uygulamalar ne tür bir mimari kullanıyor?
Çoğu büyük ölçekli uygulama, temel iş alanlarını ilişkisel tablolarda saklarken, isteğe bağlı veya özelleştirilebilir nitelikleri EAV tablolarında tutan karma bir yaklaşım kullanır.

6. EAV kötü bir tasarım deseni midir?
Kesinlikle değil. EAV, yüksek derecede dinamik veri modelleri için güçlüdür, ancak karmaşıklık getirebilir. Standart ilişkisel tablolarda verilerin verimli bir şekilde saklanabileceği durumlarda sorunlu hale gelir.

7. Bir Laravel yönetim paneli için en iyi yaklaşım nedir?
Çoğu Laravel yönetim paneli için, master tablolar varsayılan seçim olmalıdır. Kullanıcı tanımlı veya özelleştirilebilir alanlar eklemek için EAV’yi ekleyin.

8. Takımların yaptığı en büyük hata nedir?
EAV’yi her yerde gelecekteki esneklik için kullanmak. Bu genellikle karmaşık sorgular, daha yavaş raporlar ve bakım zorluklarına yol açar.

İlginç Gerçekler

1. Çoğu İlişkisel Veritabanı Sabit Şemalar İçin Optimize Edilmiştir
Geleneksel ilişkisel veritabanları, yapılandırılmış tablolar ve indeksli sütunlar etrafında tasarlanmıştır. Bu, iyi tasarlanmış master tabloların EAV modellerine göre raporlama ve analiz yükleri için genellikle daha iyi performans göstermesinin bir nedenidir. Kaynak: PostgreSQL Dokümantasyonu

2. EAV, Sağlık Hizmetleri Sistemlerinde Popüler Hale Geldi
Birçok Elektronik Sağlık Kaydı (EHR) sistemi, hastaların kayıtları binlerce olası öznitelik içerebileceğinden EAV’yi benimsedi. Bunların çoğu yalnızca belirli hastalar için geçerliydi. Bu, geleneksel şemaların bakımını zorlaştırdı. Kaynak: NCBI EAV Modelleri Üzerine Araştırma

3. Magento Tarihsel Olarak EAV’yi Geniş Bir Şekilde Kullandı
Magento, ürün öznitelikleri için EAV kullanan en tanınmış büyük ölçekli uygulamalardan biri haline geldi; bu, tüccarların veri tabanı şemalarını değiştirmeden özel ürün alanları oluşturmasına olanak tanıdı. Kaynak: Adobe Commerce Dokümantasyonu

4. Çoğu Kurumsal Sistem Karma Modelle Çalışır
Modern ERP, LMS ve CRM platformları genellikle kritik iş verilerini ilişkisel tablolarda saklarken, özelleşmiş alanlar için esnek metadata tabloları kullanarak Master Tables ve EAV kavramlarını etkili bir şekilde birleştirir. Kaynak: Martin Fowler – Metadata Mapping Pattern

Sonuç

Erken optimizasyon, her türlü kötülüğün köküdür. – Donald Knuth

Çoğu uygulama için, Master Tables varsayılan seçim olmalıdır çünkü daha iyi performans, daha basit sorgular, daha kolay raporlama ve daha düşük bakım maliyetleri sunar.

EAV yalnızca esnekliğin kritik bir iş gereksinimi olduğu durumlarda kullanılmalıdır, örneğin özel alanlar veya dinamik form oluşturucular.