Sıralama: Administration
Gruplar: Administrators
Katılan: 6.05.2014(UTC)
Mesajlar: 670
19 Kere Teşekkür Etti.
152 Mesajına Toplam 253 Kere Teşekkür Edildi.
|
Merhabalar Sql Server Proje 3 dersimiz aşağıdadır. Konu ile ilgili sorularınızı buradan sorabilirsiniz
|
Sql Server 2016 Eğitimiz 19 Mayıs tarihinde başlayacaktır. 32 Saat Olup Ücret 1450 TL + KDV'dir. Kayıt ve ayrıntılar için tıklayınıztwitter.com/dbakademi Dua ve teşekkür en büyük servetlere bedel... |
 mehmetzekikir: 5 Kişi mesajın için Teşekkür Etti.
|
|
|
|
Sıralama: Advanced Member
Gruplar: Registered
Katılan: 24.11.2014(UTC) Mesajlar: 34  5 Kere Teşekkür Etti.
2 Mesajına Toplam 2 Kere Teşekkür Edildi.
|
Bu videolu anlatım için teşekkürler, Mehmet Hocam.
Yalnız kafamda oluşan bazı soruları sormam lazım.
Bu derste diagram(ilişkisel veritbanı) oluşturmayı ve bununla beraber foreign key(yabancı anahtar) oluşturmayı anlatmışsınız.
Yalnız normalde diagram(ilişkisel veritabanı) oluşturmayı tavsiye etmediğinizi, çünkü ciddi derecede veritabanının performasını düşürdüğünü belirtmişsiniz. Neden?
Öncelikle diagram oluşturmayı tavsiye etmediğinize göre diagram oluşturmadan foreign key nasıl oluşturacağız?
Ayrıca ilişki kurmadan bu veritabanını nasıl yönetebiliriz ki?
Sormamım sebebine gelince.
Benim yeterli derecede bir Access kulanıcısıyım ve Accesste hazırladığım ticari programlar var.
Ben Accesste bu tür ilişki mutlaka kuruyorum ve ilişkilendirmede genelde ard arda sil ve güncelle seçeneğini seçiyorum.
Çünkü ilişki kurmadan imkansız veritabanını yönetmenin demiyeyim de çok zor olduğunu söyleyebilirim.
Örneğin bir sipariş tablonuz ve bir de buna bağlı bir alt sipariş tablonuz var, aralarındaki ilişki bire-çok.
Burada yanlış girilen ve ya iptal olan bir siparişi sildiğimizde ard arda sil seçeneği seçili olduğundan siç ekstra bir şey yapmadan bu siparişe bağlı alt siparişler de silinmiş oluyor.
İlişki olmayasaydı bu alt siparişler alakasız şekilde tabloda kalacaktı.
Bu konuda bizi aydınlatabilir misiniz?
|
|
|
|
|
|
Sıralama: Administration
Gruplar: Administrators
Katılan: 6.05.2014(UTC)
Mesajlar: 670
19 Kere Teşekkür Etti.
152 Mesajına Toplam 253 Kere Teşekkür Edildi.
|
Originally Posted by: maytas  Bu videolu anlatım için teşekkürler, Mehmet Hocam.
Yalnız kafamda oluşan bazı soruları sormam lazım.
Bu derste diagram(ilişkisel veritbanı) oluşturmayı ve bununla beraber foreign key(yabancı anahtar) oluşturmayı anlatmışsınız.
Yalnız normalde diagram(ilişkisel veritabanı) oluşturmayı tavsiye etmediğinizi, çünkü ciddi derecede veritabanının performasını düşürdüğünü belirtmişsiniz. Neden?
Öncelikle diagram oluşturmayı tavsiye etmediğinize göre diagram oluşturmadan foreign key nasıl oluşturacağız?
Ayrıca ilişki kurmadan bu veritabanını nasıl yönetebiliriz ki?
Sormamım sebebine gelince.
Benim yeterli derecede bir Access kulanıcısıyım ve Accesste hazırladığım ticari programlar var.
Ben Accesste bu tür ilişki mutlaka kuruyorum ve ilişkilendirmede genelde ard arda sil ve güncelle seçeneğini seçiyorum.
Çünkü ilişki kurmadan imkansız veritabanını yönetmenin demiyeyim de çok zor olduğunu söyleyebilirim.
Örneğin bir sipariş tablonuz ve bir de buna bağlı bir alt sipariş tablonuz var, aralarındaki ilişki bire-çok.
Burada yanlış girilen ve ya iptal olan bir siparişi sildiğimizde ard arda sil seçeneği seçili olduğundan siç ekstra bir şey yapmadan bu siparişe bağlı alt siparişler de silinmiş oluyor.
İlişki olmayasaydı bu alt siparişler alakasız şekilde tabloda kalacaktı.
Bu konuda bizi aydınlatabilir misiniz? Merhabalar , söyle acıklayayım, Büyük ölçekli verilerler çalışıyorsanız koydugunuz her foregin key sizin insert update ve delete işlemlerinizi yapmadan önce mutlaka karşınıza çıkacaktır, biraz daha açmak gerekirse her işlemi yapmadan önce gidip kontrol edecektir, bu büyük boyutlu verilerde ve işlemlerde sizi aşırı derece yavaşlatacaktır, peki bunu kullanmadan nasıl ilişkiyi kuracağız? Yaptığımız projelerde farkındaysanız hep aktif kolonu var bunun sebebi işte bu ilişkiyi kurmaktır. İlişkileri bir b tree yapısı olarak düşünürseniz, zaten biz asla ama asla en alt kademe dışında veri silmiyoruz, silmek yerine gidip aktifini 1 den 0 a çekiyoruz, aslında neredeyse bütün kurumsal yapılarda sistem böyle işlemektedir. Access ufak boyutlu verilerle çalıştıgı için sizin accesste ilişki tanımlamanızda bir sıkıntı olmaz ama tanımlamazsanız emin olun daha performanslı olur |
Sql Server 2016 Eğitimiz 19 Mayıs tarihinde başlayacaktır. 32 Saat Olup Ücret 1450 TL + KDV'dir. Kayıt ve ayrıntılar için tıklayınıztwitter.com/dbakademi Dua ve teşekkür en büyük servetlere bedel... |
|
|
|
|
|
Sıralama: Advanced Member
Gruplar: Registered
Katılan: 24.11.2014(UTC) Mesajlar: 34 5 Kere Teşekkür Etti.
2 Mesajına Toplam 2 Kere Teşekkür Edildi.
|
Originally Posted by: mehmetzekikir
Merhabalar , söyle acıklayayım,
Büyük ölçekli verilerler çalışıyorsanız koydugunuz her foregin key sizin insert update ve delete işlemlerinizi yapmadan önce mutlaka karşınıza çıkacaktır, biraz daha açmak gerekirse her işlemi yapmadan önce gidip kontrol edecektir, bu büyük boyutlu verilerde ve işlemlerde sizi aşırı derece yavaşlatacaktır, peki bunu kullanmadan nasıl ilişkiyi kuracağız? Yaptığımız projelerde farkındaysanız hep aktif kolonu var bunun sebebi işte bu ilişkiyi kurmaktır.
İlişkileri bir b tree yapısı olarak düşünürseniz, zaten biz asla ama asla en alt kademe dışında veri silmiyoruz, silmek yerine gidip aktifini 1 den 0 a çekiyoruz, aslında neredeyse bütün kurumsal yapılarda sistem böyle işlemektedir.
Access ufak boyutlu verilerle çalıştıgı için sizin accesste ilişki tanımlamanızda bir sıkıntı olmaz ama tanımlamazsanız emin olun daha performanslı olur
Yani, bu durumda, yanlış anlamadıysam, büyük ölçekli verilerle çalışacaksak foreign key tanımlanmasını tavsiye etmiyorsunuz. Performans olayına gelince sadece güncelleme ve silmelerde mi düşmekte, yoksa here veri okuduğunda mı?
|
|
|
|
|
|
Sıralama: Administration
Gruplar: Administrators
Katılan: 6.05.2014(UTC)
Mesajlar: 670
19 Kere Teşekkür Etti.
152 Mesajına Toplam 253 Kere Teşekkür Edildi.
|
Originally Posted by: maytas Originally Posted by: mehmetzekikir
Merhabalar , söyle acıklayayım,
Büyük ölçekli verilerler çalışıyorsanız koydugunuz her foregin key sizin insert update ve delete işlemlerinizi yapmadan önce mutlaka karşınıza çıkacaktır, biraz daha açmak gerekirse her işlemi yapmadan önce gidip kontrol edecektir, bu büyük boyutlu verilerde ve işlemlerde sizi aşırı derece yavaşlatacaktır, peki bunu kullanmadan nasıl ilişkiyi kuracağız? Yaptığımız projelerde farkındaysanız hep aktif kolonu var bunun sebebi işte bu ilişkiyi kurmaktır.
İlişkileri bir b tree yapısı olarak düşünürseniz, zaten biz asla ama asla en alt kademe dışında veri silmiyoruz, silmek yerine gidip aktifini 1 den 0 a çekiyoruz, aslında neredeyse bütün kurumsal yapılarda sistem böyle işlemektedir.
Access ufak boyutlu verilerle çalıştıgı için sizin accesste ilişki tanımlamanızda bir sıkıntı olmaz ama tanımlamazsanız emin olun daha performanslı olur
Yani, bu durumda, yanlış anlamadıysam, büyük ölçekli verilerle çalışacaksak foreign key tanımlanmasını tavsiye etmiyorsunuz. Performans olayına gelince sadece güncelleme ve silmelerde mi düşmekte, yoksa here veri okuduğunda mı? Evet kesinlikle tavsiye etmiyoruz, direk sunucuyu işgal ettiği için sunucunun performasnını düşürüyor |
Sql Server 2016 Eğitimiz 19 Mayıs tarihinde başlayacaktır. 32 Saat Olup Ücret 1450 TL + KDV'dir. Kayıt ve ayrıntılar için tıklayınıztwitter.com/dbakademi Dua ve teşekkür en büyük servetlere bedel... |
|
|
|
|
|
Sıralama: Advanced Member
Gruplar: Registered
Katılan: 24.11.2014(UTC) Mesajlar: 34 5 Kere Teşekkür Etti.
2 Mesajına Toplam 2 Kere Teşekkür Edildi.
|
Originally Posted by: mehmetzekikir Originally Posted by: maytas Originally Posted by: mehmetzekikir
Merhabalar , söyle acıklayayım,
Büyük ölçekli verilerler çalışıyorsanız koydugunuz her foregin key sizin insert update ve delete işlemlerinizi yapmadan önce mutlaka karşınıza çıkacaktır, biraz daha açmak gerekirse her işlemi yapmadan önce gidip kontrol edecektir, bu büyük boyutlu verilerde ve işlemlerde sizi aşırı derece yavaşlatacaktır, peki bunu kullanmadan nasıl ilişkiyi kuracağız? Yaptığımız projelerde farkındaysanız hep aktif kolonu var bunun sebebi işte bu ilişkiyi kurmaktır.
İlişkileri bir b tree yapısı olarak düşünürseniz, zaten biz asla ama asla en alt kademe dışında veri silmiyoruz, silmek yerine gidip aktifini 1 den 0 a çekiyoruz, aslında neredeyse bütün kurumsal yapılarda sistem böyle işlemektedir.
Access ufak boyutlu verilerle çalıştıgı için sizin accesste ilişki tanımlamanızda bir sıkıntı olmaz ama tanımlamazsanız emin olun daha performanslı olur
Yani, bu durumda, yanlış anlamadıysam, büyük ölçekli verilerle çalışacaksak foreign key tanımlanmasını tavsiye etmiyorsunuz. Performans olayına gelince sadece güncelleme ve silmelerde mi düşmekte, yoksa here veri okuduğunda mı? Evet kesinlikle tavsiye etmiyoruz, direk sunucuyu işgal ettiği için sunucunun performasnını düşürüyor Peki hocam bu durumda aklıa gelen soru şu. Hal böyleyken foreign key neden icat edildi ve webte bununla ilgili pek çok döküman mevcut. Yani kullanılması uygun görülmüyorsa üzerinde bu kadar durulmamalı bence, ama SQL ile ilgili eğitim video vemakalalerinde enin eboynuna anlatılıyor.
|
|
|
|
|
|
Sıralama: Member
Gruplar: Registered
Katılan: 22.11.2014(UTC) Mesajlar: 19 10 Kere Teşekkür Etti.
5 Mesajına Toplam 6 Kere Teşekkür Edildi.
|
Originally Posted by: maytas Originally Posted by: mehmetzekikir Originally Posted by: maytas Originally Posted by: mehmetzekikir
Merhabalar , söyle acıklayayım,
Büyük ölçekli verilerler çalışıyorsanız koydugunuz her foregin key sizin insert update ve delete işlemlerinizi yapmadan önce mutlaka karşınıza çıkacaktır, biraz daha açmak gerekirse her işlemi yapmadan önce gidip kontrol edecektir, bu büyük boyutlu verilerde ve işlemlerde sizi aşırı derece yavaşlatacaktır, peki bunu kullanmadan nasıl ilişkiyi kuracağız? Yaptığımız projelerde farkındaysanız hep aktif kolonu var bunun sebebi işte bu ilişkiyi kurmaktır.
İlişkileri bir b tree yapısı olarak düşünürseniz, zaten biz asla ama asla en alt kademe dışında veri silmiyoruz, silmek yerine gidip aktifini 1 den 0 a çekiyoruz, aslında neredeyse bütün kurumsal yapılarda sistem böyle işlemektedir.
Access ufak boyutlu verilerle çalıştıgı için sizin accesste ilişki tanımlamanızda bir sıkıntı olmaz ama tanımlamazsanız emin olun daha performanslı olur
Yani, bu durumda, yanlış anlamadıysam, büyük ölçekli verilerle çalışacaksak foreign key tanımlanmasını tavsiye etmiyorsunuz. Performans olayına gelince sadece güncelleme ve silmelerde mi düşmekte, yoksa here veri okuduğunda mı? Evet kesinlikle tavsiye etmiyoruz, direk sunucuyu işgal ettiği için sunucunun performasnını düşürüyor Peki hocam bu durumda aklıa gelen soru şu. Hal böyleyken foreign key neden icat edildi ve webte bununla ilgili pek çok döküman mevcut. Yani kullanılması uygun görülmüyorsa üzerinde bu kadar durulmamalı bence, ama SQL ile ilgili eğitim video vemakalalerinde enin eboynuna anlatılıyor. Şimdi maytas hocam kullanılmaması diye bir şey yok mehmet hoca yapıyı kurarız biliriz ama uygulamada foreıgn keyle ilişki kurmayız diyor ki sanırım ambarlar için konuşuyor ilişkisel veritabanlarında bu ilişkiler kuruluyor zaten veri ambarlarında zaten hiç bir şekilde veri silinmiyor normalize edilmiyor bu sebeple ilişki büyük datalarda sunucuyu yavaşlatıyor siz küçük datalar için düşünüyorsunuz büyük ambarlar için bu yapılar sunucuyu meşgul ediyor bu diyagramlar kuruluyor biliniyor ama ambar yapısında kullanılmıyor. Normalize ilişkisel veritabanlarının olmazsa olmazı zaten bu key yapısı.
|
|
|
|
|
|
Sıralama: Administration
Gruplar: Administrators
Katılan: 6.05.2014(UTC)
Mesajlar: 670
19 Kere Teşekkür Etti.
152 Mesajına Toplam 253 Kere Teşekkür Edildi.
|
Originally Posted by: diaboli Originally Posted by: maytas Originally Posted by: mehmetzekikir Originally Posted by: maytas Originally Posted by: mehmetzekikir
Merhabalar , söyle acıklayayım,
Büyük ölçekli verilerler çalışıyorsanız koydugunuz her foregin key sizin insert update ve delete işlemlerinizi yapmadan önce mutlaka karşınıza çıkacaktır, biraz daha açmak gerekirse her işlemi yapmadan önce gidip kontrol edecektir, bu büyük boyutlu verilerde ve işlemlerde sizi aşırı derece yavaşlatacaktır, peki bunu kullanmadan nasıl ilişkiyi kuracağız? Yaptığımız projelerde farkındaysanız hep aktif kolonu var bunun sebebi işte bu ilişkiyi kurmaktır.
İlişkileri bir b tree yapısı olarak düşünürseniz, zaten biz asla ama asla en alt kademe dışında veri silmiyoruz, silmek yerine gidip aktifini 1 den 0 a çekiyoruz, aslında neredeyse bütün kurumsal yapılarda sistem böyle işlemektedir.
Access ufak boyutlu verilerle çalıştıgı için sizin accesste ilişki tanımlamanızda bir sıkıntı olmaz ama tanımlamazsanız emin olun daha performanslı olur
Yani, bu durumda, yanlış anlamadıysam, büyük ölçekli verilerle çalışacaksak foreign key tanımlanmasını tavsiye etmiyorsunuz. Performans olayına gelince sadece güncelleme ve silmelerde mi düşmekte, yoksa here veri okuduğunda mı? Evet kesinlikle tavsiye etmiyoruz, direk sunucuyu işgal ettiği için sunucunun performasnını düşürüyor Peki hocam bu durumda aklıa gelen soru şu. Hal böyleyken foreign key neden icat edildi ve webte bununla ilgili pek çok döküman mevcut. Yani kullanılması uygun görülmüyorsa üzerinde bu kadar durulmamalı bence, ama SQL ile ilgili eğitim video vemakalalerinde enin eboynuna anlatılıyor. Şimdi maytas hocam kullanılmaması diye bir şey yok mehmet hoca yapıyı kurarız biliriz ama uygulamada foreıgn keyle ilişki kurmayız diyor ki sanırım ambarlar için konuşuyor ilişkisel veritabanlarında bu ilişkiler kuruluyor zaten veri ambarlarında zaten hiç bir şekilde veri silinmiyor normalize edilmiyor bu sebeple ilişki büyük datalarda sunucuyu yavaşlatıyor siz küçük datalar için düşünüyorsunuz büyük ambarlar için bu yapılar sunucuyu meşgul ediyor bu diyagramlar kuruluyor biliniyor ama ambar yapısında kullanılmıyor. Normalize ilişkisel veritabanlarının olmazsa olmazı zaten bu key yapısı. Şimdi durumu söyle anlatayım Büyük ve kurumsalsistemlerde foregin key kullanılmaz neden performans için peki hiç mi kullanılmaz? 2 tip veri tabanı oluşturulur, biri gerçek sistem digeri ise model sistem, eğer orm kullanıyorsan mutlaka ilişkilerin belli olduğu yani foregin keylerin model sistem oluşturulur. Ama canlı sistemde keyler kullanılmaz, ambarlarda ise kesinlikle zaten kullanılmaz |
Sql Server 2016 Eğitimiz 19 Mayıs tarihinde başlayacaktır. 32 Saat Olup Ücret 1450 TL + KDV'dir. Kayıt ve ayrıntılar için tıklayınıztwitter.com/dbakademi Dua ve teşekkür en büyük servetlere bedel... |
|
|
|
|
|
Sıralama: Advanced Member
Gruplar: Registered
Katılan: 24.11.2014(UTC) Mesajlar: 34 5 Kere Teşekkür Etti.
2 Mesajına Toplam 2 Kere Teşekkür Edildi.
|
Originally Posted by: mehmetzekikir
Şimdi durumu söyle anlatayım
Büyük ve kurumsalsistemlerde foregin key kullanılmaz neden performans için peki hiç mi kullanılmaz?
2 tip veri tabanı oluşturulur, biri gerçek sistem digeri ise model sistem, eğer orm kullanıyorsan mutlaka ilişkilerin belli olduğu yani foregin keylerin model sistem oluşturulur.
Ama canlı sistemde keyler kullanılmaz, ambarlarda ise kesinlikle zaten kullanılmaz
Hocam, sözünü ettiğiniz orm olayını daha yeni, sizden duydum. Bunun üzerine nette araştırdım, ama her yerde genel bilgi verilmiş. Örnekli açıklama olmayınca anlaması kolay olmuyor. Malüm bir nusubet bin nasihata bedel misali şu orm olayını ve üstte bahsettiğiniz 2 tip veritanı(gerçek ve model sistem) hakkında örnekli eiğitim videosu çekebilir misiniz? İnanıyorum ki bir çok kişinin işine yarayacaktır.
|
|
|
|
|
|
Forumu Atla
Bu foruma yeni konular postalayamazsınız.
Bu forumda ki konulara yeni posta gönderemezsiniz.
Bu forumdaki postalarınızı silemezsiniz.
Bu forumdaki postalarınızı düzenleyemezsiniz.
Bu forumda anketler yaratamazsınız.
Bu forumdaki anketlere oy veremezsiniz.
