SQL veritabanlarında veriler nasıl saklanmalı?

Arsen Lüpen

Hectopat
Katılım
28 Şubat 2021
Mesajlar
102
Daha fazla  
Cinsiyet
Erkek
Sorum şu: Kullanıcıların tutulduğu bir user tablomuz olsun. Bu tabloda her bir kullanıcı 1 satırlık yer kaplıyor. Şimdi bu kullanıcıya ait ürünlerin tutulduğu bir products tablomuz olduğunu varsayalım. Bu tabloda user_id, product_id ve product_name diye üç alanımız olsun. User_id'si 1 olan kullanıcının 10 tane ürünü olduğunu düşünelim. Bu durumda aslında bu kullanıcı için 10 satır olmuş oluyor. Milyonlarca kullanıcı olduğunu ve her bir kullanıcının onlarca, yüzlerce, belki de binlerce ürünü olduğunu düşündüğümüzde, milyarlarca hatta katrilyonlarca satır oluşması demektir.

Bu tarz One-to-many ilişkisi olan tablolar foreign key ilişkisi ile mi tutulmalı yoksa hashtable kullanarak her bir kullanıcının ürünleri sadece 1 satır mı kaplamalı? Yani, user_id ve product şeklinde iki alan olacak. Product alanında hashtable olacak ve içinde product_id ile product_name keyleri olacak. Böylece kullanıcıya ait tüm veriler product alanı altında hashtable içerisinde tutulacak.

Ya da bu durum daha farklı nasıl yapılabilir? Çok veri olmaması için belirli aralıklarla veri temizliği yapılmasını önerebilirsiniz. Bu ürün mantığında olabilir; kullanıcı bir ürün satın aldığında ve üzerinden 1 yıl geçtiğinde o veriye gerek kalmayabilir. Ancak, Tinder mantığında bir kaydırma işlemi yapıyorsak, yani tabloda swiper ve swiped_user diye iki alan varsa, bir kullanıcının kaydırdığı her bir kullanıcı 1 satır veri oluşturacak. Bu da bir sürü satır demek. Burada veri temizleme işlemi yapamayız çünkü, kullanıcının sola kaydırdığı bir kişi ile bir daha hiç eşleşmemesi gerekmektedir. Burada da bir sürü satır olmaması için swiped_users adı altında bir hashtable alanı oluşturulup. Swpied_user_id ve swipe_direction şeklinde iki key verilip 1 kullanıcıya ait tüm veriler birden fazla satır ile değil de 1 satırda 1 alan içinde saklanmış olur.
 
Bu tarz One-to-many ilişkilerinde veriyi nasıl saklamak gerektiği konusu, performans, veritabanı boyutu ve veri erişim hızı gibi faktörleri dikkate alarak dengelenmesi gereken bir konudur. İki ana yaklaşım vardır: normalized (normalleştirilmiş) ilişkisel model ve denormalize edilmiş veya NoSQL tarzı modeller.
 
Aslinda binlerde kullanici ve hepsinin de satin aldigi onlarca urun varsa dedigin gibi milyonlarca veri DB de saklanabilir ve bu sorun degil DB icin. Dogru indexleme yaparsan performans sorunu yasamazsin. DB de sharding ve clustering yaparak read ve write operasyonlarini optimize edebilirsin.

Burada dikkat etmen gereken sey "urun" ile "sepetteki urun" ve "siparisteki urun" kavramlarinin 3 farkli sey oldugunu gozden kacirmaman. Bir urunun fiyati degisirse kullanicinin satin aldigi urunun fiyati degismemeli.

Eger sorun performans ise dedigim gibi zaten dogru DB dizayni ile bu sorunu asarsin. Bunun maliyeti fazla olacaktir fakat binlerce siparis varsa sorun olmaz, para geliyor demektir.

---

Eger tinder'daki gibi "swipe" eventlerini saklamak istiyorsan bunu relational DB de yapmak zorunda degilsin. Cunku bu eventler bir defa gerceklesir, diger eventlerle sadece 1 ya da 2 key uzerinden relate edilebilir ve muhtemelen hic update edilmezler. Bunun icin daha iyi spesyalize olmus DB ler ya da Cassandra gibi high throughput yapilar kullanabilirsin.

Yine de tavsiyem is o noktaya geldiginde optimizasyonu dusunmen. Baslangicta bu tarz teknolojilerle yola baslaman seni yavaslatacaktir. "premature optimization is the root of all evil" D.Knuth
 
Cevaplarınız için teşekkür ederim. SQL mi nosql mi bunu öğrenmek istemiyorum. Optimizasyon konusunda evet haklısınız. Sadece veri saklama işinde relational tablo modelleri kullanarak One-to-many ilişkisi gibi bir ilişki ile bir kullanıcıya ait birden fazla satır oluşturularak verinin tutulması mı yoksa hashtable kullanılması mı onu merak ettim. Ama cevaplarınızdan anladığım kadarıyla çok bir farkı yok, veri güncelleniyorsa One-to-many güncellenmiyorsa da hashtable gibi bir yapı kullanılabilir gibi anladım.
 
Dosya. T.C. benzeri bir site yönetiyorum, her kullanıcının yüklediği dosyaları "uploads" kullanıcıları ise "users" tablosunda tutuyorum.

Dediğiniz hashtable benzeri bir yöntem olarak, "uploads" propertylerini JSON yapıp, base64 ile encodeliyorum.

Bir veri sileceksem önce base64 decode, sonra JSON decode yapıp veriyi silip tekrar oluşturuyorum. Ekleme içinde aynı.

Bu sayede bir kullaniciya ait milyonlarca veriyi tek bir rowda tutuyorum.

Yalnız eğer veriye sürekli erişmen gerekiyorsa çok dinamik bir alt yapın varsa düz tutmanı öneririm, yani "select" operasyonunu istersen 50 data içeren istersen 1 milyon data içeren dB de çalıştır, bir fark olmaz.
 

Technopat Haberler

Yeni konular

Geri
Yukarı