Tüm Platformlar için Hızlı Uygulama Geliştirme Kitap Yayın Süreci
Kitap gözden geçirilmek üzere BTG (Bilgi ve Teknoloji Grubu) 'na gönderildi. 05.10.2018-14:10
BTG (Bilgi ve Teknoloji Grubu) tarafından iki sayfalık bir reklam tasarımı bekleniyor. 08.10.2018 - 15:30

Konuyu Paylaş : facebook gplus twitter

Konuyu Oyla:
  • Derecelendirme: 5/5 - 1 oy
  • 1
  • 2
  • 3
  • 4
  • 5
Tablodaki field sayısı ne kadar önemli
#11
Normalizasyon kurallarını sağlamak önemli fakat arkadaş 170 alandan bahsetmis benzer olayi bizde yasiyoruz ne kadar normalizasyona uyacam desende bazen uyamazsin mikronun bu sekilde yoksa 400 tablosu vardir uysa kac bin tablo olucak bunu siz dusunun hersey teorideki gibi olmuyor
Yalnızım ama bir kente yürüyen ordu gibiyim, edebiyattan kaçınmalıyım..
Cevapla
#12
Güzel bir konuya değinilmiş. Sıklıkla önerdiğim ve uyguladığım bir husus veritabanı normalizasyonu. Madde madde okumayı daha çok sevdiğimiz için, içinde bulunduğum veritabanı projelerinde neler yaptığımı ifade edeyim:

  1. Tablolarımın içindeki alanlar mantıksal olarak o tablo için anlamlı alanlardır. O tablo için anlamını kaybeden bir alanın yeri bir başka tablodur. (OOP'de olduğu gibi)
  2. Her bir alanın veri tipi üzerinde çok ince bir şekilde düşünülür. Örneğin Cinsiyet alanı için Bit, Varchar(1) ya da tinyint gibi veri türü seçenekleri bulunur iken; başka veri türleri seçilmez.
  3. Check Constraint olabilecek tüm alanlar için birer check constraint yazılır.
  4. Başka tablolar ile alakalı alanlar kesinlikle bir foreign key ile bağlanılır.
  5. NULL değer alabilecek ve alamayacak alanlar üzerinde düşünülür ve gerçekten NULL olabilecek alanlar tespit edilir. Diğerlerinin NULL olmasına izin verilmez.
  6. Her bir tablonun içinde ID isminde, auto increment olan bir Primary Key kesinlikle olur. (İsminin ID olması önemli)
  7. Her tabloda en az bir tane unique key kesinlikle bulunur, bulunamaz ise bir şekilde icat edilir.
  8. Tablo içindeki alan sayısının 15-20 bandının üstüne çıktığı görüldüğünde; tasarımda bir hata olabileceği değerlendirilir ve parçalamanın yolları aranır.
  9. Tabloya gereksiz yere fazla sayıda index tanımlanmaz. (Şu alanı da indexleyelim ileride faydası olur denilmez)
  10. Her bir tablo için; SELECT, INSERT, UPDATE ve DELETE cümleciklerini içeren birer Stored Procedure yazılır. (Stored Procedure'lerin performansa olumlu etkileri gerekir ise ayrıca konuşulabilir)
  11. İş kuralları veritabanı içinde de kontrol edilir. Bir alanın alabileceği değerler, bir kaydın yapılabilmesi için gereken koşullar, ilgili ID alanlarının varlıklarının kontrolü gibi kontroller SQL Server için Instead Of Triggerlarında kodlanır. Bir kaydın işlem görmesinden sonra etkilenecek unsurlar ise, After triggerlarında kodlanır. (Gerekir ise bu konu hakkında da fikir paylaşımında bulunabilirim, nedenleri anlamında)
  12. Uygulama (Delphi'de ya da başka bir dilde yazdığınız) içinde kesinlikle SQL cümleleri yer almaz.
Şimdilik benim takip ettiğim metodolojiler bu şekilde. Aklıma gelmeyenler olur ise ileride onları da eklerim. İlk bakışta zor bir disiplin olarak görünebilir; ancak alıştıkça ve faydalarını gördükçe, böyle bir disipline uymanın hazzı bir başka oluyor. Sigarayı bıraktıktan sonra, yediğiniz içtiğiniz şeylerin, tabiatın kokusunu alabilmek gibi.(Sigarayı bırakmak bir eziyet gibi görünebilir ama bırakmanın getirisi eziyetinden her zaman daha fazladır)
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla
#13
Aslında bunu proje bazında da değerlendirmek gereklidir. Tek kullanıcılı binlerce, onbinlerce kayıt girilmeyecek bir proje ise istediğiniz kadar alan ekleyin. Bunun yanında Bahadır beyin dediği şekilde kurallara uyarsanız proje küçükte olsa büyükte olsa ileride başınız ağrımaz, en çok delphi tarafında biraz daha fazla kod yazarsınız.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
WWW
Cevapla
#14
Ben konuya farklı bir yönden bakarak bilgi eksikliğimin olduğunuda düşünerek soruyorum.
Bu soruyu sorarken özellikle delphi'yi baz alıyorum.
Genelde piyasada yazılan programlarda gördüğüm kadarı ile SQL Server üzerinde SP'ler Veri çekmek ve toplu iş yapmak için kullanıyor.
Buraya kadar herşey güzel diyelim.
Peki 1 tabloda 20 adet field olsun
Kullanıcı tarafında Ins/Upd işlemleri için dataset'e bağlı olarak tasarladığımızı düşünelim.
Post ettiğimizde (bildiğim kadarı ile) Update için sadece değişen alanlar veritabanı üzerinde update ediliyor.
Şimdi soru şu Ins/Upd işlerini SP ile yapmamız öneriliyorsa nasıl yapmalıyız?
Bu alanlardan hangilerinin değiştiğini nasıl algılamalıyız?
Yoksa tüm fieldları her seferinde parametremi geçmeliyiz?
Tüm parametreleri geçmek performansı etkilermi?
Tüm parametreler geçilirse sadece değişenlermi update olur yoksa sql buna nasıl bir davranış gösterir?
Bu konuda deneyimli üstadlarımızın fikir ve görüşlerini öğrenmek isterim.
Bu dünyada kendine sakladığın bilgi ahirette işine yaramaz. 
Cevapla
#15
Esasen inst/update'in sp.de olması veri bütünlüğü amaçlı diye biliyorum. Siz hangi arayüzden bilgi girerseniz girin sp.den girdiğiniz sürece veritabanı seviyesinde kontrolünüzü yapar ve bütünlüğü sağlarsınız. Hemde şöyle bir durum var yazdığınız program hem mobile de çalışacak hem masaüstünde diyelim. Ve veritabanı yapısında bir değişiklik yaptınız. Hem mobilde o veritabanını kullandığınız her yerde hemde masa üstünde güncelleme gerekir. Ama kaydı sp.den yapıyorsanız yordamınızı günceller bütün uygulamalarıda güncellemiş olursunuz.
Topluluk mopluluk yok :/
Cevapla
#16
(29-03-2018, Saat: 11:03)boreas Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlEsasen inst/update'in sp.de olması veri bütünlüğü amaçlı diye biliyorum. Siz hangi arayüzden bilgi girerseniz girin sp.den girdiğiniz sürece veritabanı seviyesinde kontrolünüzü yapar ve bütünlüğü sağlarsınız. Hemde şöyle bir durum var yazdığınız program hem mobile de çalışacak hem masaüstünde diyelim. Ve veritabanı yapısında bir değişiklik yaptınız. Hem mobilde o veritabanını kullandığınız her yerde hemde masa üstünde güncelleme gerekir. Ama kaydı sp.den yapıyorsanız yordamınızı günceller bütün uygulamalarıda güncellemiş olursunuz.

Boreas hocam teorikte bunun ideal olduğu aşikar
Fakat pratikte bu işler nasıl yürüyor benim öğrenmeye çalıştığım bu
Cevabınızda nasıl sorusunun yanıtını göremedim
Bu dünyada kendine sakladığın bilgi ahirette işine yaramaz. 
Cevapla
#17
(29-03-2018, Saat: 11:42)adelphiforumz Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
(29-03-2018, Saat: 11:03)boreas Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlEsasen inst/update'in sp.de olması veri bütünlüğü amaçlı diye biliyorum. Siz hangi arayüzden bilgi girerseniz girin sp.den girdiğiniz sürece veritabanı seviyesinde kontrolünüzü yapar ve bütünlüğü sağlarsınız. Hemde şöyle bir durum var yazdığınız program hem mobile de çalışacak hem masaüstünde diyelim. Ve veritabanı yapısında bir değişiklik yaptınız. Hem mobilde o veritabanını kullandığınız her yerde hemde masa üstünde güncelleme gerekir. Ama kaydı sp.den yapıyorsanız yordamınızı günceller bütün uygulamalarıda güncellemiş olursunuz.

Boreas hocam teorikte bunun ideal olduğu aşikar
Fakat pratikte bu işler nasıl yürüyor benim öğrenmeye çalıştığım bu
Cevabınızda nasıl sorusunun yanıtını göremedim

Kurduğunuz mimariye göre bu işin teorik doğrusu değişiyor. Çok katmanlı mimaride (ki çok kullanıcılı veri tabanı programlarını çok katmanlı mimari ile tasarlamak en doğrusudur) iş kurallarını veri tabanı katmanına yüklemezsiniz. Dolayısıyla da INSERT/UPDATE/DELETE işlemleri için SP tanımlamanıza gerek kalmaz, çünkü zaten bunları başka bir katmanda yapıyorsunuz ve o katman ister SP kullanır, ister SQL cümlesi, isterse de ORM kütüphanesi. O katmanın nasıl tasarlanacağı başka bir tartışma konusu.

Pratikte işler şöyle yürüyor: Projenin büyüklüğü, programcının kalitesi ve disiplini ve projenin devamlılığına göre programcı en uygun olanını seçiyor Smile Genelde de iki katmanlı mimari seçiliyor, çünkü yazması daha kolay ve hızlı. Eğer proje küçükse veya tecrübesiz bir programcıysa CRUD (Create, Retrieve, Update, Delete) işlemlerini kodun için yazıyor. Tecrübeli programcılar SP kullanıyor. Kimi programcılar ise ikisini karıştırıyor. Örneğin karmaşık sorguları SP olarak yazıyor, ama basit sorguları kodun için yazıyor. 

Benim tavsiyem ise belli bir seviyeye gelene kadar kurallara uygun gidin. Gerekirse proje uzun sürsün. Bir süre sonra zaten nerede kuralları esneteceğinizi kendiniz çözeceksiniz.

İyi çalışmalar
Cevapla
#18
Teşekkür ederim.
Cevapla
#19
(29-03-2018, Saat: 10:37)adelphiforumz Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlBen konuya farklı bir yönden bakarak bilgi eksikliğimin olduğunuda düşünerek soruyorum.
Bu soruyu sorarken özellikle delphi'yi baz alıyorum.
Genelde piyasada yazılan programlarda gördüğüm kadarı ile SQL Server üzerinde SP'ler Veri çekmek ve toplu iş yapmak için kullanıyor.
Buraya kadar herşey güzel diyelim.
Peki 1 tabloda 20 adet field olsun
Kullanıcı tarafında Ins/Upd işlemleri için dataset'e bağlı olarak tasarladığımızı düşünelim.
Post ettiğimizde (bildiğim kadarı ile) Update için sadece değişen alanlar veritabanı üzerinde update ediliyor.
Şimdi soru şu Ins/Upd işlerini SP ile yapmamız öneriliyorsa nasıl yapmalıyız?
Bu alanlardan hangilerinin değiştiğini nasıl algılamalıyız?
Yoksa tüm fieldları her seferinde parametremi geçmeliyiz?
Tüm parametreleri geçmek performansı etkilermi?
Tüm parametreler geçilirse sadece değişenlermi update olur yoksa sql buna nasıl bir davranış gösterir?
Bu konuda deneyimli üstadlarımızın fikir ve görüşlerini öğrenmek isterim.

Kendi uyguladığım yöntemleri paylaşarak, merkanızı gidermeye çalışayım.

Kullandığımız component'lere göre değişiklik arz edebiliyor. BROWSE stored procedure'ü vasıtası ile çektiğim datayı (TADOStoredProc ya da ona benzer componentler ile) eğer kullandığım component'in CachedUpdates özelliği yok ise; bir Memory Dataset'in içine atıyorum. Bir TADOQuery ya da TADOStoredProc vasıtası ile çekilen Dataset üzerinde Insert/Update/Delete işlemlerini yapmıyorum ! Bu tarz işlemler Ad-Hoc query oluştururlar ve performanslı değildirler. Aynı zamanda risklidirler. (Bir SELECT sorgusunun birden fazla tablo ile Join olduğunu ve bu sonuç seti üzerinden Delete işlemi yaptığınızı hayal edin.)

 Dolayısı ile memory dataset kullandığım için(ya da CahchedUpdate özelliği olan bir dataset), yapılan değişiklikler asla ben yansıtmadan veritabanını etkilemiyor. Memory dataset üzerinden silenen kayıtları tespit edebilmek için içinde sadece ID alanı olan temp bir memory dataset daha kullanıyorum. İş yapılan tüm değişikliklerin veritabanına yansıtılmasına geldiğinde;
  • Bir transaction başlatıyorum.
  • Silinen kayıtların ID'lerini içeren memory dataset içinde baştan sona dönerek Delete stored procedure'ümü çağırıyorum.
  • Daha sonra, orjinal memory dataset'im üzerinde dönüyorum ve Insert/Update stored procedurelerimden birisini çağırıyorum. (Bir kaydın değişip değişmediğini, yeni eklenip eklenmediğini anlamanın bir çok yolu var. Bunu sunan hazır componentler de var. Hatta TClientDataSet component'inde Delta property'si mevcut.)
  • Bu işlemler sırasında bir hata oluşur ise daha önce başlkattığım transaction'ımı Rollback ediyorum; hata olmadı ise Commit ediyorum.
Umarım size bir fikir verebilmişimdir.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla
#20
Her ne yaptı isem; yukarıdaki yorumumu düzenleyip yeniden gönderemedim. Bu nedenle; buraya yazacağım:

Yazdığım yanıtı ve sizin sorunuzu yeniden okuyunca, bazı hususlara yanıt vermediğimi gözlemledim. Update işlemi SP tarafında nasıl olmalı ? Ben bazın Insert ve Update işleminin ikisini de yapabilen bir adet stored procedure yapıyorum. Memory Dataset üzerinde yeni bir kayıt eklendiğinde (OnNewRecord) bu ID alanını -1'e set ediyorum. İlgili procedure'ün yapısı aşağı yuları şu şekilde oluyor:

ALTER PROCEDURE [dbo].[sp_Birim_Tanimlari_INSERT_UPDATE]
@ID INT,
@Tartilimi VARCHAR(1) = NULL,
@BirimAdi VARCHAR(15) = NULL,
@BirimCarpani DECIMAL(21, 6) = NULL
AS
SET NOCOUNT ON;

BEGIN TRANSACTION;

IF EXISTS(
SELECT 1
FROM dbo.t_Birim_Tanimlari
WHERE
ID = @ID
)
BEGIN
BEGIN TRY
UPDATE dbo.t_Birim_Tanimlari
SET
Tartilimi = ISNULL(@Tartilimi ,Tartilimi ),
BirimAdi = ISNULL(@BirimAdi ,BirimAdi ),
BirimCarpani = ISNULL(@BirimCarpani ,BirimCarpani )
WHERE
ID = @ID
END TRY
BEGIN CATCH
IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;

EXEC sysSaveErrors;

RETURN -1;
END CATCH
END
ELSE
BEGIN
BEGIN TRY
INSERT INTO dbo.t_Birim_Tanimlari
( 
Tartilimi, 
BirimAdi, 
BirimCarpani 
)
SELECT
@Tartilimi, 
@BirimAdi, 
@BirimCarpani 
END TRY
BEGIN CATCH
IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;

EXEC sysSaveErrors;

RETURN -1;
END CATCH
END

IF @@TRANCOUNT > 0 COMMIT TRANSACTION;
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla

Konuyu Paylaş : facebook gplus twitter





Konuyu Okuyanlar: 1 Ziyaretçi