[]
Veritabanı tasarımı vol 2
Dün de sormuştum bu gün bir daha biraz farklı soru sorayım. Şimdi bir ilan sitesi düşünelim bu ilan sitesinde emlak ilanı, ikinci el araba, motor ilanı ne bileyim, bu ve benzeri ilanlar verilebilir olsun.
Bunu sadece emlağa indilerim, emlakta ne olabilir, arsa olabilir, müstakil ev olabilir, villa olabilir, yazlık olabilir, apartman dairesi olabilir. Bunların ortak özellikleri ne? yüzölçümleri, fiyatları ve krediye uygun olup olmadıkları. ortak olmayan özelliklere örnek vermek gekirse, mesela bina yaşı bir arsanın özelliği olamaz.
İşte burda benim kafamı kurcalayan konu ortaya çıkıyor:
Bu durumda farklı kategorilere ait özellikleri nasıl saklamamız gerekir? Her kategori için ayrı tablo mu tutmalıyız, fikirleriniz nedir?
Bunu sadece emlağa indilerim, emlakta ne olabilir, arsa olabilir, müstakil ev olabilir, villa olabilir, yazlık olabilir, apartman dairesi olabilir. Bunların ortak özellikleri ne? yüzölçümleri, fiyatları ve krediye uygun olup olmadıkları. ortak olmayan özelliklere örnek vermek gekirse, mesela bina yaşı bir arsanın özelliği olamaz.
İşte burda benim kafamı kurcalayan konu ortaya çıkıyor:
Bu durumda farklı kategorilere ait özellikleri nasıl saklamamız gerekir? Her kategori için ayrı tablo mu tutmalıyız, fikirleriniz nedir?
dikey bir tablo yapısı düşünebilirsin.
mesela birinci tablon emlak diyelim:
id - adı - fiyatı - ili ....
1 - avcılarda ev - 100000 - 34
2 - süper arsa - 50000 - 45
değişken olabilecek diğer tüm özellikleri farklı bir tabloda satır satır key/value şeklinde tutarsın. mesela ozellik tablondaki 1 id'li emlak için olan kayıtlar
emlak_id - key -value
1 - krediye_uygun_mu - true
1 - bina_yasi - 9
1 - yuzolcumu - 100
gibi
mesela birinci tablon emlak diyelim:
id - adı - fiyatı - ili ....
1 - avcılarda ev - 100000 - 34
2 - süper arsa - 50000 - 45
değişken olabilecek diğer tüm özellikleri farklı bir tabloda satır satır key/value şeklinde tutarsın. mesela ozellik tablondaki 1 id'li emlak için olan kayıtlar
emlak_id - key -value
1 - krediye_uygun_mu - true
1 - bina_yasi - 9
1 - yuzolcumu - 100
gibi
- lord seithel (27.11.13 00:56:17)
Bugün hazırlıklı geldim.
i.imgur.com
i.imgur.com
Bana kalırsa seninki de 2.resim a'daki gibi yapılmalı.
i.imgur.com
i.imgur.com
Bana kalırsa seninki de 2.resim a'daki gibi yapılmalı.
- nickini vermek istemeyen uye (27.11.13 00:59:03)
@lord seithel key value tablosunda emlakId foreign key oluyor dimi? ve ilanı refere ediyor? Ortak özellikleri bir tabloda, ilana göre değişen özellikleri de ( ilanın tipine, daire, arsa vs olması ) key value tablosunda tut diyorsun. Saklamak olarak tamam olur sanırım ama bir de olaya ekrana basılma tarafından bakmak gerekir. Şimdi böyle bir tablo düzeninde ekrana basılmak istendiği zaman mesela, eğer ilan daireyse ekrana bina yasini, yuzolcumunu vesaireyi bastır, yok değil arsaysa, şunu bunu bastır gibi bir ton kontrol yapmak gerekmez mi? bu da sıkıntı değil mi?
- sahipsiz (27.11.13 01:05:19)
@nickini vermek istemeyen uye senin verdigin resme bakınca da her bir kategori için ayrı tablo görüyorum?
- sahipsiz (27.11.13 01:06:20)
relationonal db haricinde birseyler dusunebilirsin. mongo db misal.
onun haricinde soyle birsey aklima geliyor. ozelliklere isim verme, birinci ozellik ikinci ozellik gibi alanlar olsun. ayri bi yerde her kategori icin bu alanlarin neyi ifade ettigini tutabilirsin. onun haricinde search yapilmicak alanlar icin o kayida ait tum ozellikleri misal json formatinda bi alanda tutabilirsin.
onun haricinde soyle birsey aklima geliyor. ozelliklere isim verme, birinci ozellik ikinci ozellik gibi alanlar olsun. ayri bi yerde her kategori icin bu alanlarin neyi ifade ettigini tutabilirsin. onun haricinde search yapilmicak alanlar icin o kayida ait tum ozellikleri misal json formatinda bi alanda tutabilirsin.
- badseed (27.11.13 03:55:41)
Aslında tek başına veritabanı tasarımı olmaz, o veritabanının uzerinde çalışacak uygulamanın ihtiyaçlarına göre bir dizayn yapman gerekir. Bu tarz konuların ucu açıktır, bir sürü çözüm - yaklaşım bulabilirsin ve hepside kendi içinde doğrudur.
Mesela, uygulamanda bu parametrelerde arama yaptırmayacaksan, bu değişken parametreleri json haline çevirip hepsini tek bir kolonda saklayabilirsin. Ama senin bahsettiğin ilan sitesinde bu uygun bir çözüm olmaz.
lord seithel söylediği yöntem senin problemine en yakın çözümü üretir, ne kadar normalize edeceğin ise yine yapacağın uygulamanın ihtiyaçlarına bağlı.
Mesela, uygulamanda bu parametrelerde arama yaptırmayacaksan, bu değişken parametreleri json haline çevirip hepsini tek bir kolonda saklayabilirsin. Ama senin bahsettiğin ilan sitesinde bu uygun bir çözüm olmaz.
lord seithel söylediği yöntem senin problemine en yakın çözümü üretir, ne kadar normalize edeceğin ise yine yapacağın uygulamanın ihtiyaçlarına bağlı.
- sekizbit (28.11.13 01:21:51)
Son olarakda soyle bisi yapabilirsin belki. ozellikleri sutun sutun degil de ayri kayitlar olarak tutabilirsin. 3 kolonlu bi tablon olsun. ilk kolon ilan numarasi ikinci kolon ozellik adi/turu ve son kolon da ozellik degeri.
misal
ilanNo ozellik deger
101, kira, 750
101, alan, 110
102, motorhacmi, 1300
105, cpu, 1.7ghz
Burdaki sorun su farkli ozelliklerin degerleri farkli data tipine uygun olabilir. Ya hepsini text olarak tutacaksin ki bu searchlerde performans sorunu yaratir. Ya da 2/3 tablo tutabilirsin. Biri text degerliler icin bir digeri sayi degerliler icin (bunu int ve float degerler icin iki tabloya da ayirabilirsin cok optimize yapacaksan) Farkli tablolarda tutarsan dez avantaj olarak ilan bilgilerini cekerken 2/3 tabloyada sorgulama yapman gerekecek bir de database'e atarken hangi tabloya atcagina hangi ozelligin gidecegini bilmen lazim.
Son olarakda performansi artirmak icin ozellik isimlerini text olarak degil de int olarak tanimlayabilirsin kodda. bolece search performansin artar. yani kira, alan, hacimi birer int olarak tanimla ILAN_OZELLIK_KIRA = 1 gibi kodu yazarken anlasilir olur boylece.
misal
ilanNo ozellik deger
101, kira, 750
101, alan, 110
102, motorhacmi, 1300
105, cpu, 1.7ghz
Burdaki sorun su farkli ozelliklerin degerleri farkli data tipine uygun olabilir. Ya hepsini text olarak tutacaksin ki bu searchlerde performans sorunu yaratir. Ya da 2/3 tablo tutabilirsin. Biri text degerliler icin bir digeri sayi degerliler icin (bunu int ve float degerler icin iki tabloya da ayirabilirsin cok optimize yapacaksan) Farkli tablolarda tutarsan dez avantaj olarak ilan bilgilerini cekerken 2/3 tabloyada sorgulama yapman gerekecek bir de database'e atarken hangi tabloya atcagina hangi ozelligin gidecegini bilmen lazim.
Son olarakda performansi artirmak icin ozellik isimlerini text olarak degil de int olarak tanimlayabilirsin kodda. bolece search performansin artar. yani kira, alan, hacimi birer int olarak tanimla ILAN_OZELLIK_KIRA = 1 gibi kodu yazarken anlasilir olur boylece.
- badseed (03.12.13 17:30:20 ~ 19:23:01)
1