Veritabanı özellikleri neden yok sayılıyor ve bunun yerine orta katmanda yeniden keşfediliyor?

Günümüzde çoğu BT projesinin Oracle 11g ve SQL Server 2008 gibi modern veritabanı motorlarında bulunan zengin özelliklerin göz ardı edilmesinin ( "veritabanı bağımsızlığı" dışında) başlıca nedenleri nelerdir ?

Ya da Helsinki Bildirgesi blogundan ödünç almak gerekirse :

Geçtiğimiz yirmi yılda, DBMS içinde kullanabileceğimiz işlevselliğin (özelliklerin) katlanarak büyüdüğünü gözlemliyoruz. Bu özellikler veritabanı uygulamaları oluşturmamızı sağladı. Doksanlı yıllarda hepimizin yapmaya başladığımız şey buydu.

Ama sonra yeni milenyumun şafağında bir şey oldu. Ve gizemli bir şekilde bir veritabanı uygulama projesi içindeki DBMS'nin rolünü önemsiz hale getirdi. (...) Yeni milenyum itibarıyla, tüm uygulama mantığını DBMS'den orta katman sunuculara itiyoruz. DBMS dışında uygulanan öğelerin işlevselliği patladı ve zengin özelliklere sahip DBMS, satır depolamadan başka bir şey için neredeyse hiç kullanılmıyor.

Gibi şeylerden bahsediyoruz

• Veri API'leri olarak kullanılan depolanan prosedürler (güvenlik için ve aşırı ağ trafiğini önlemek için)
• Gerçekleştirilmiş görünümler
• Tetikleyiciler yerine
• Hiyerarşik sorgular (bağlanma yöntemi)
• Coğrafya (uzamsal veri türleri)
• Analitik (olası satış, gecikme, toplama, küp vb.)
• Sanal Özel Veritabanı (VPD)
• Veritabanı düzeyinde Denetim
• Flashback sorguları
• Veritabanında XML üretimi ve XSL dönüşümü
• Veritabanından HTTP belirtme çizgileri
• Arka plan iş planlayıcı

Bu özellikler neden kullanılmıyor? Neden çoğu Java, .NET ve PHP geliştiricisi "SELECT * FROM mytable" yaklaşımını benimsiyor?

Çünkü saklı prosedürler:

• başka bir geliştirme dili ekleyerek karmaşıklığı ve potansiyel olarak fazlalık kodu (her iki dilde yazılmış mantık);
• genellikle PHP, C #, Java, Python, vb .'den daha kötü araçlar, izleme ve hata ayıklama yeteneklerine sahiptir;
• çoğu orta kademe dilden genellikle daha az yeteneklidir;
• yalnızca minimum gerçek kullanım olan yüksek hacimli veri dönüşümünde (sunucu gidiş dönüşünden kaçındığınız yerde) bir avantaja sahip olursunuz.

Bununla birlikte, C # ASP.NET uygulamalarında yaygın bir metodolojidir.

Jeff Atwood'un dediği gibi, depolanan prosedürler veritabanlarının montaj dilidir ve insanlar ihtiyaç duymadıkça montaj dilinde kodlama eğiliminde değildir.

Sıklıkla somutlaşmış görünümler kullandım ve bazen Oracle'da CONNECT BY kullandım, ikisinin de MySQL'de var olduğuna inanmıyorum.

Veritabanında XML / XSLT kullanma eğiliminde değilim çünkü bu, XML ve XSLT kullandığım anlamına geliyor.

Coğrafi veya uzamsal veri yapılarına gelince, muhtemelen sadece "toparlamanın" zor olmasının nedeni. Oldukça uzmanlık alanı. Uzamsal veri yapıları üzerine MySQL kılavuzunu okudum ve eminim kapsamlı CBS deneyimine sahip biri için mantıklı geliyor ama benim için ve benim (bir noktanın enlem / boylamını işaretleme eğiliminde olan) sınırlı ihtiyaçlarım için mantıklı geldiğinden eminim Bunu anlamak için zaman yatırımına değmez.

Diğer bir sorun ise, ANSI SQL'in (çok) ötesine geçerseniz, kendinizi belirli bir veritabanı satıcısına ve muhtemelen belirli bir sürüme bağladınız demektir. Bu nedenle, uygulama geliştiricilerin veritabanlarını en düşük ortak paydada ele alma eğiliminde olduklarını sık sık göreceksiniz, bu da onlara ilişkisel veriler için bir damping alanı olarak davranmak anlamına gelir.

Çünkü geliştiriciler SQL'i bilmiyor. Hibernate gibi araçlar tarafından oluşturulan DDL ve DML'ye ve JPA ek açıklamaları gibi dil düzeyinde yapılara güvenirler. Geliştiriciler, bunların korkunç derecede verimsiz olup olmadığını umursamıyorlar çünkü bunlar merhametle normal günlük seviyeleri tarafından gizleniyorlar ve DBA'lar geliştirme ekiplerinin parçası değiller.

Bu yüzden iBATIS araçlarını seviyorum . DBMS'ye özgü özellikler dahil olmak üzere SQL yazmanızı ve anlamanızı sağlar.

Sanırım bunun bir nedeni, satıcıya kilitlenme korkusu.

Bu çok sık söylenmiyor, ancak satıcıya özgü özellikleri kullanmanın faydalarının maliyete karşı tartılması gerekiyor. Temel olarak, desteklemek istediğiniz her veritabanı için satıcıya özgü özelliklere dayanan parçaları yeniden yazmak zorunda olmanın maliyeti. Satıcı daha iyi bir yol sağladığında, bir şeyi genel amaçlı bir şekilde uygularsanız, bir performans maliyeti de vardır.

Şu örneği açacağım: Analiz Servisleri, Raporlama Servisleri vb. Uygulamanız için yapabilecekleri her şeyi fark ettiğinizde, SQL Server'ın "kilitlenmesi" daha kabul edilebilir olabilir. Büyük ticari veritabanı sistemleri için, dikkate alınması gereken "sadece" SQL veritabanı motoru değildir.

"Veritabanı özellikleri neden göz ardı ediliyor".

Birçok sözde geliştirici veri yönetimi konusunda tamamen bilgisiz olduğundan ve daha kötüsü, onlar da cehaletlerini tamamen bilmezler. "Vasıfsız ve farkında değil", kime bu bir çan çalıyor.

Yazılımınız istemcinizin donanımında çalışıyorsa, veritabanındaki herhangi bir değişiklik (yeni Depolanan Prosedürler, güncellenmiş görünümler, vb.) Veritabanı yönetici hakları gerektirecektir. Bu, müşteriler için neredeyse her zaman bir sorundur. DB grubunu dahil etmek, yapmanız gereken tüm güncellemeleri karmaşık hale getirir. Burada sunulan pek çok harika neden var, ancak veba gibi veritabanına kod eklemekten kaçınmam gereken tek şey bu.

Sanırım bunun bir nedeni, satıcıya kilitlenme korkusu. Bu DBMS özellikleri standartlaştırılmamıştır - örneğin, depolanan prosedürler çok DB'ye özgüdür ve depolanan prosedürleri kullanarak bir şeyler uyguladıysanız (örneğin, bir orta katman aracılığıyla sunulan web hizmetleri yerine), o zaman sonsuza kadar ilk seçilen DBMS'ye bağlı kalırsınız. , (yani, DBMS'yi değiştirmek istiyorsanız başka bir DBMS'de yeniden uygulamak için zaman / para harcamak istemediğiniz sürece).

MySQL.

1990'ların sonunda ve 2000'lerin başında web uygulamaları patladığında, MySQL 3.3 veya 4.0 sürümündeydi ve basit SELECTs'nin üzerinde hiçbir şeyi desteklemiyordu . Bununla birlikte, ücretsizdi ve çoğu Linux dağıtımıyla birlikte kuruldu. Sonuç olarak, bir nesil programcı veritabanları hakkında bilgi sahibi olmadı ve onları nasıl kullanacağını bilmedi.

MySQL'in 5.1'de olmasına ve ticari bir sistemin özelliklerinin çoğunu desteklemesine rağmen, yeni bir LAMP projesi başlatıldığında aynı kirli eski bloglar ve makaleler şablon olarak kullanılıyor ve MySQL, MyISAM tabloları ve 3.3 dönemi işlevselliği ile dağıtılıyor .

SQL, Haskell gibi aynı nedenden dolayı başarısız oluyor. Dil başarısını belirleyen ölçü saflık değil, bilgisayarlar tarafından yorumlama kolaylığı değil, içinde yazılmış programları sürdürmenin ne kadar zor olduğudur.

Ölümlüler en basit dille bile başarısız olur. Belki 10 kişiden 1'i C # gibi basit bir dil kullanma becerisine sahiptir. Ancak bu% 10'un içinde, tüm insanların yalnızca% 10 veya% 1'i SQL veya Haskell gibi dilleri etkili bir şekilde kullanabilir.

Şimdi, SQL ile yapabileceğiniz çok az şey olduğu için SQL bir dil olarak eksiktir. Her zaman başka bir dile ihtiyacınız olacak. Bu SQL için hangi rolü bırakıyor? Geliştiriciler, ACID'nin düz dosya depolamaya göre avantajlarını anlayacaklar, ancak bunun yanında veritabanlarının gerçekten onlara sunacak hiçbir şeyi yok.

İkinci bir sorun, SQL'in Kaynak Sürümlendirme ile etkili bir şekilde uyumlu olmamasıdır. SQL gerçekten ilk seferde doğru yaptığınız fikri üzerine inşa edilmiş görünüyor. Yani, sadece geliştiriciler için uygun değil, aynı zamanda geliştirme süreci için de yetersiz bir eşleşme.

Orta katmanı düzeltmek / yeniden konuşlandırmak DBMS'den daha kolaydır.

Bu muhtemelen mimarinize bağlıdır, ancak bu bizim sebebimizdir. Bunu, daha yoğun ve (muhtemelen) geliştiricilerimizden daha fazla maaş alan bir DBA'ya sahip olduğumuz gerçeğiyle birleştirin. Tüm geliştiriciler SQL'i bilir ve bazıları prosedürel dilde yarı bilgilidir. Gerçekten zor bir üretim problemi ortaya çıkarsa, mimarinin öyle ya da böyle daha iyi olacağına bakılmaksızın, geliştiricilerin orta katmanda çalışmaları veritabanından daha kolay ve daha hızlı olacaktır.

Bu tür özelliklerin varlığından haberdar olmayan pek çok kişiyle karşılaştım - mySQL'in ilk günlerinde dişlerini kestiler ve gerçekten başka hiçbir şey kullanmadılar ve mySQL'deki yeni depolama tablolarının ilerlemesi bile. Veya okulda veri tabanlarını öğrendiler ve kaçırdıkları her şeyi görmek için asla geri dönmediler.

Başa çıkmaları gereken minimum SQL'i öğrenirler ve farklı RDBMS'lerin sunduğu farklı uzantıların tümünü fark etmezler.

Bir projede somut görüşlere sahip olmayı çok isterdim ... ama Postgres kullanıyorum. Uzamsal veri türlerini başka bir proje için kullanmayı çok isterdim, ancak mySQL'in boş olmadıkları konusundaki ısrarı ile başa çıkmak için bir hack yapmam veya veritabanlarını değiştirmem gerekecek. MySQL'de sorun olmayacak bir OLTP'de uzun süre çalışan sorgularla başa çıkmak için Oracle'ın işlem tutarlılığını nasıl devre dışı bırakacağımı bile bulmak zorunda kaldım.

Normalde belirli bir problem için veritabanının eksiklikleri etrafında kod yazabilirim, ancak sorunun bir kısmı iş için doğru aracı seçmektir - mevcut bir projede, veri kopyalamaya adam-ay harcadık çünkü biz Postgres'i kullandılar ve Slony-1'e ne kopyalayacağımızı bilmeden önce karar verdiler.

... Ben gibi varlık olarak bu soruyu görüntülemek 'neden olmasın fazla insan kullanıyor musunuz özellik x içinde dil y ' - onlar bir uzman değilseniz y dilin onlar bilmiyor olabilir x özelliği bulunmaktadır.

(ve bunu DBA sertifikası almak için destek olarak almayın ... Islak çuvaldan çıkış yolunu programlayamayan bazı Oracle DBA'ları tanıyorum; 8i günlerindeki tüm kursları aldım, ancak o grupla bir araya gelmek istemediğim için testleri almayı reddetti)

Bence geri kalan her şeyi gölgede bırakan en büyük neden, birden fazla uygulama aynı verileri paylaşırken ilişkisel veritabanı sistemlerinin çarpıcı biçimde daha önemli hale gelmesi. Codd'un ünlü makalesi "Büyük Paylaşılan Veri Bankaları için İlişkisel Veri Modeli " (vurgu benim) başlıklı .

İnsanlar şu anda yazdıkları uygulamanın her zaman kendi ekipleri tarafından kontrol edileceğini düşünme eğilimindedir; ve uygulama tarafından oluşturulan verilerle ilgilenen kişilerin her zaman tüm ihtiyaçlarını karşılayacağını. Yeni bir ihtiyaç ortaya çıkarsa, bu yeni bir uygulama oluşturarak değil, mevcut bir uygulamaya yeni bir özellik eklenerek karşılanacaktır.

Ancak çoğu durumda (elbette hepsi değil; her durum farklıdır), bu geliştirme modeli uzun vadede pek iyi işlemiyor. Uygulama tarafından üretilen veriler biriktikçe ve işletme için daha önemli hale geldikçe, farklı kişilerin verilerin nasıl kullanılacağı konusunda ilginç fikirleri olacaktır. Bu olduğunda, ilişkisel bir veritabanı yönetim sisteminiz yoksa, büyük bir zorluğun içindesiniz demektir.

Ölçeklenebilirlik. Veritabanı sunucusuna ne kadar çok iş verirseniz, daha büyük bir darboğaz olur. Verileri işleyen bütün bir yük dengeli uygulama sunucularına sahip olmak ve veritabanını bir kalıcılık deposu olarak kullanmak daha ölçeklenebilir.

Kurumsal politikaların ("SQL Sunucusuna erişim iznimiz olmadığı için, milyonlarca satırı işlemek ve başka bir tablodaki milyonlarca satırla buna katılmak için Access gibi daha az güçlü bir DBMS kuralım ve bu içe aktarmayı otomatikleştirelim .. ") veya olabilecek teknik politikalar (" Access'in bu miktarda veriyi idare edebileceğini ve yapmasa bile MDB'yi birkaç MDB'ye bölüp bunlara referans verebileceğimizi biliyorum ..... ")

UGH. Kurumsal siyaset ve teknik siyaset hatta cehalet birçok özelliği kullanmamı engelledi.

Başka bir örnek - SQL Server'ın tercih edilen DBMS olduğu% 100 Microsoft mağazasında saklı yordamları kullanmamak için bir neden göremiyorum . Ancak, çözüme sonunda sahip olacak olan BT görevlisi, SP'lerde "hafif" olduğu için, başka önlemlere başvurmak zorunda kaldım. Demek istediğim, bu "özelliğin" neden dükkanlarında onlar tarafından görmezden gelindiğinin mükemmel bir örneği var.

Hala DOS Foxpro 2 kullanan başka bir mağaza biliyorum çünkü tek BT ​​personeli mevcut sistemi bu şekilde yazmış ve tüm yeni şeyler bu şekilde geliştirilecek. Neden? Zamana ayak uyduramaz mıyız? Oradaki pazarlamacıların birçoğunun aynı anda açık birkaç DOS komut istemi var ve şimdiye kadar gördüğüm en çirkin raporları üretmek için Foxpro "işleri" çalışıyor. Ama işe yarıyor - onlara bunu vereceğim. İşe yarıyor - ana masalarında 12 milyon sıra ve bu ana masaya 'katıldıkları' 50'den fazla başka masa var (aynı anda 50'nin tamamı değil) ama adam ... 1991'i geride bıraktı! Sorunuzda verdiğiniz madde işaretli listeden bir öğeyi tartışmak bile istemiyorlar.

Sanırım bunun gibi şeyler bu yüzden.

En büyük neden, çoğu insanın onları bilmemesi olduğunu söyleyebilirim. Birisi bir soruna çözüm bulduğunda, bu, benzerleri için varsayılan çözüm haline gelir. SELECT * FROM tablosu birçok kişi için uzun süredir çalışıyor, bu yüzden eski sorunlara yeni yaklaşımlar aramakla uğraşmıyorlar.

Diğer bir neden de, bazen onu kodda yazmanın bir veritabanı kullanmaktan çok daha kolay olmasıdır. Kendi ürününüzü yuvarlamakla, kullanıma hazır bir bileşen satın almakla aynı fikirdir. Önceden yazılmış bir özelliği kullanmak, sorunlarınızı birçok kez çözebilir, ancak arada bir, önceden yazılmış bileşenlerin yapabileceklerinin dışında bir şey yapmanız gerekir.

Güzel soru ve güzel tartışma.

Bunu ifade etmenin başka bir yolu da "neden nesne DB'leri yakalanmadı?" madalyonun diğer yüzü olan. DB'ler, hala her uygulamaya sızan sinir bozucu bir soyutlama olmaya devam ediyor, ancak modern uygulamaların OO mantığıyla uyumsuzlar.

ActiveRecord, Hibernate ve diğer ara yazılımlarda DB'lerin işlevselliğini gizleyip çoğaltmamız gerçekten garip bir durumdur. Ancak kırılma noktasındaki paradigmalara olan budur ("Nesne-ilişkisel empedans uyumsuzluğu"). OO uygulamalarımıza benzer veritabanı teknolojilerine (örneğin, nesne DB'leri) hiç geçiş yapacak mıyız?

Cevap "uzun bir süre için değil" ve bu arada, orta katmanın işlevselliği boşluğu doldurmak için büyüdükçe, birçok durumda DB'nin göz ardı edilmesini ve ezilmesini ve sadece satır depolaması için kullanılmasını bekleyin.

Başka bir soru da "orta katman yapabiliyorsa bunu neden DB'de yapayım?" Orta kademe tanıdıktır ve her zaman hız ve işlevsellik açısından zemin kazanıyor. Yine, OO-RDMS uyuşmazlığını önlemek için orta katmanı kullanıyoruz.

Christian'ın ölçeklenebilirlik hakkında söylediklerine devam etmek için .

Basitçe, mantık Uygulama Sunucularına taşınırken RDBM'ler daha çok saf veri depoları olarak kullanılmaktadır. AS'nin ekstra katmanı, geliştiricilere RDBMS'yi Uygulama Sunucusu olarak kullanmaktan daha fazla esneklik sağlar.

Daha önce, Fat Apps ve Client Server'ın klasik günlerinde, DB ve Uygulama Sunucusu temelde aynıydı. Ya fat istemci kodunuza gömülü uygulama mantığına sahiptiniz ya da onu RDBMS'ye geri gönderdiniz. Ancak o zamanlar, birincil iletişim biçimi doğrudan veritabanına SQL idi.

Günümüzde, diğer uygulama protokolleri daha yaygındır (CORBA, DCOM, Remote EJB ve günümüzde HTTP üzerinden XML / JSON / HTTP-RPC tarzı protokoller giderek daha yaygın). Çoğu veritabanı bu protokollere doğrudan yanıt vermez, bu nedenle bu çağrıları durdurmak için bir Uygulama katmanı araya girer ve bu katman veritabanını çağırır.

Ama öğrendiğimiz gibi, artık bu katmana mantık koyarak çok daha fazla esneklik elde ediyoruz. Daha geniş araç seçenekleri, önbelleğe alma veya yük devretme konusunda daha fazla esneklik ve hatta veritabanı teknolojisi (RDMBS, OODBMS, CouchDB gibi Belge depoları). Bu "yeni", 3. katman, eklenen karmaşıklığa rağmen, getirdiği karmaşıklıktan daha fazla esneklik ve güç ekler.

Uygulama katmanınız, Depolanan Prosedürlerin üzerinde çok ince bir kaplama olduğunda, neden orada olduğunu sorgulamak geçerlidir.

Veritabanından ve tüm özelliklerinden yararlanmak bugün bile geçerli bir uygulama stratejisidir. SQL Server, Oracle vb. Son derece güçlü yazılım parçalarıdır.

O zaman bile, üçüncü kademe, modern bir sisteme esneklik katmada son derece yararlıdır.

Benim için sebep sadece uygulamalarımın veritabanından bağımsız olması değil, aynı zamanda temel CRUD işlevlerini en iyi şekilde oluşturan bir veritabanıdır. Evet, veritabanları son derece optimize edilmiştir ve bir HTTP belirtme çizgisi oluşturabilir, ancak bunu neden yapasınız? Bir web hizmeti / web uygulaması, bir veritabanı değil, HTTP çağrıları için optimize edilmiştir. Tıpkı bir uygulamanın doğrudan bir veri dosyasına bağlanmak ve verileri almak için tasarlanmaması gibi. Yapılabilir mi? Evet ama neden? Bu, uygulamanızın MÜKEMMELDİR.

Kişisel olarak, depolanmış prosedürler dışında bahsettiğiniz her şeyin uygulamaya ait olduğunu hissediyorum. Mimarinizin X olduğunu biliyorsanız, X'in özelliklerinden yararlanın, uygun olduğunda DB sunucusuna aktarın, vb ... Eğer X veya Y (veya Z) olabilirse, uygulamanız agnostik olmalıdır. uygulamayı yeniden düzenlemeniz gerekebileceğinden emin olarak iş güvenliği oluşturmaya çalışmak :). Bence biraz tembellik, rahatlık ile birleştiğinde bununla bir ilgisi olabilir. Mümkünse SQL yerine C # ile yapmayı tercih ettiğimi biliyorum. . . C # becerilerim daha iyi.

İlk olarak: ORM kullanan herhangi bir geliştirici, bir ORM kullanmanın SQL becerilerine sahip olmayı reddettiğini düşünüyorsa saftır. SQL oluşturan çoğu ORM, nesne sorgularının nasıl oluşturulduğuna bağlı olarak yayılan SQL'i değiştirir. Geliştiricinin, nesne sorgularından herhangi birini değiştirmeleri gerekip gerekmediğini görmek için SQL'i analiz etmesi gerekecektir.

Kısa cevap: Bu özelliklerin çoğu OO geliştirme için pratik değildir. DBA'ların bunu duymaktan hoşlanmadıklarını biliyorum ama gerçek bu. Bu özellikler uç durumlar için iyidir ve N / Hibernate gibi çoğu iyi ORM, bu uç durumlar için SQL sağlamanıza izin verir.

Çoğunlukla CRUD'a yetki verilmesi söz konusu olduğunda:

Uzun cevap: Bence RDBMS dünyası, olgunlukta artan ağrılardan geçiyor ve dünyadaki yerini buluyor. Gerçek: OOP, RDBMS'den daha eskidir. OOP büyüyen acılarından ve olgunlaşmasından yeni çıkıyor. Bence bir dil olarak SQL çok olgun, ancak bir RDBMS'nin neyi idare etmesi gerektiği fikri henüz yerleşmiş durumda. RDBMS, Java ve C # gelene kadar çoğu web uygulamasının iş mantığını elinde tutuyordu. Sanırım şimdi bu düzeltmeyi hissetmeye başlıyoruz.

Bununla birlikte, herhangi bir ORM tasarımcısının size RDBMS'ye beslenen sql ifadelerinin kalitesinin önemli olmadığını söyleyeceğini sanmıyorum.

CRUD dışı söz konusu olduğunda burada bir cevabım yok. Bildiğim çoğu mağaza hala ETL / vb için DB kullanıyor ...

Aynı mantığı DB veya orta katmana uygulamak söz konusu olduğunda, tüm bu özellikleri normal bir 'orta katman' programcı için gerçekten fark yaratacak düzeyde bilen yeterli geliştirici yoktur. Belki de bu özellikler hakkında derinlemesine bilgi sahibi olan bekar insanlar DBA'lardır. Ve bunlar geliştirmeden başka sorunlara odaklanıyor. DBA'lardan daha fazla 'normal' geliştirici var. Bu yüzden ekibiniz için doğru kişileri bulmak çok zor ve maliyetli olacaktır.

Diğer bir nokta da, normalde yalnızca tek bir veritabanı sistemi hakkında derinlemesine bilgi toplayacağınızdır, hepsi değil. Böylece SQL Server uzmanlarına veya Oracle uzmanlarına sahip olabilirsiniz, ancak her ikisine birden sahip olamazsınız. Bu, yüksek uzmanlık gerektiren uygulama alanlarının daralmasına (bir dereceye kadar) yol açar. Öyleyse, bu tür uygulamalar için pazar, orada olsa bile o kadar büyük değil.

Sanırım nedeni, satıcıya bağlı kalma ve RDBM kullanıcılarının çoğunun bilgi eksikliğinin bir kombinasyonu. SQL bir programlama dilidir ve hem SQL'i çağırdığınız dili hem de SQL'i öğrenmek, özellikle SQL özellikle benzersiz bir dil olduğu için, bir veya diğerine hakim olmaktan çok daha zordur.

Bence çözüm, veritabanı işlevselliğinizi bir yardımcı sınıf olarak soyutlamak ve sınıfın sahipliğini SQL ile ne yaptıklarını bilen birkaç kullanıcıya vermek. Bu, satıcıya kilitlenme riskini en aza indirir (satıcıları değiştirirseniz, yeniden yazılan tek şey sınıftır). Bu ayrıca SQL konusunda uzman olmayan geliştiricilere soyutlanmış bir arayüz sağlar, böylece veritabanıyla doğrudan uğraşmak zorunda kalmazlar.

Artan veritabanı işlevselliğinden yararlanmada gördüğüm bir endişe, ölçeklendirmedir. Veritabanı yükünüzü web / uygulama sunucu yüküne göre ölçeklendirmek çok daha zor bir teklif gibi görünüyor.

Seçenekleriniz sınırlıdır, daha hızlı donanımla ölçeklendirme (bazen çok daha yüksek lisans maliyetleri ile) veya karmaşık, salt okunur kopyalarla ölçeklendirme vb.

Performans sorunları varsa, bunların web sunucusu uygulama düzeyinde olmasını istiyorum. En azından seçeneklerimden biri başka bir web sunucusu eklemek ve yükü dağıtmaktır.

Web sunucusu ile veritabanı sunucusu arasında gönderilen ağ trafiği (kayıtlar) miktarını en aza indirmek için veritabanı düzeyi koduna karşı çıkmıyorum. Diğer özelliklere karşı tartışıyorum, örneğin. veritabanı düzeyinde kapsamlı iş mantığı işleme.

Birkaç gönderi, uygulama katmanında ölçeklendirmenin db katmanına göre daha ucuz olduğunu belirtiyor.

Göz önünde bulundurulması gereken bir diğer husus, birden çok veri deposuna erişen bileşik uygulamalardır. Uygulama katmanında platformdan bağımsız sorgu dili yazmak ve sürdürmek, db katmanındaki ayrı platforma özgü sorgulara göre çok daha kolaydır.

Çünkü ana bilgisayar dilinde, ana bilgisayar dili nesneleriyle nesne yönelimli yazılım yazmak, yordamsal yazılım yazmaktan daha iyidir.

Her zaman birçok müşteriye satılan ve müşterinin donanımında çalışan sistemler üzerinde çalıştım. Bu şunlara yol açar:

• İstemcinin veritabanı yazılımının hangi sürümünü çalıştıracağını bilmiyorsunuz.
• Müşteriler, lisans maliyetleri veya mevcut BT politikası nedeniyle veritabanı yazılımını dilediğiniz zaman güncellemeye istekli olmayabilir.
• Gerçekleştirilmiş görünümler gibi temel özellikler, veritabanı yazılımının yalnızca bazı "sürümlerinde" olsa bile, daha küçük müşteriler genellikle veritabanının yüksek son sürümü için ödeme yapmaya istekli değildir.
• Er ya da geç satış elemanlarınızdan biri, yazılımınızın farklı bir satıcının RDBMS'si ile kullanılmasını kabul edecektir.
• Mantığı orta kademede bir kez yazmak veya veritabanında en azından PL-SQL ve TSQL arasında seçim yapmak kolay bir seçimdir!
• Veritabanındaki herhangi bir değişiklik (yeni Saklanan Prosedürler, güncellenmiş görünümler, vb.) Veritabanı yönetici hakları gerektirecektir; bu, bazı müşterilerin sitesinde çok daha zor olabilir ve ardından yalnızca yazılımınızı güncelleyebilir.
• Veritabanını güncellemek için bir komut dosyası yazmak, uygulamanın dll'lerinin yeni bir sürümünü yüklemekten her zaman daha zordur. (Bugünlerde çoğu derleme sistemi, her derlemenin bir parçası olarak MSI dosyalarını çıktılar)
• Bir veritabanındaki kodu birim test etmek, daha sonra orta katmandan daha zordur.
• Depolanan işlemlerde hata ayıklamak C # 'dan daha zordur.
• Veritabanınızda çalışması, müşterinin veritabanında çalışacağı anlamına gelmez, RDBMS'nin çalışma şeklini değiştiren çok sayıda anahtarı vardır - müşteriler her zaman bunları farklı şekillerde ayarlama eğilimindedir.

Bu nedenle, yukarıdakilerin tümü göz önüne alındığında, bir veritabanı özelliğini kullanmanın kazancı , uzun vadeli acıya değmeden önce büyük olmalıdır .