RDBMS'ler nasıl bir heves olarak kabul edilebilir?

11

Bilgi İşlem A düzeyimi 2003 yılında tamamlayarak 2007 yılında Bilgi İşlem alanında derece alarak ve çok fazla SQL kullanımı olan bir şirkette ticaretimi öğrenerek, İlişkisel Veritabanlarının depolama amacıyla kullanılması fikrini gündeme getirdim.

Bu nedenle, geliştirmeye nispeten yeni olmasına rağmen, şu yorumu okuyarak şaşırdım ( https://softwareengineering.stackexchange.com/q/89994/12436 ):

[Bazı geliştiriciler] [SQL] 'i hor görür ve RDBMS'nin bir heves olduğunu düşünür

Açıkçası, yetkin bir geliştirici doğru iş için doğru aracı kullanacak ve örneğin düz dosya veya depolama için başka bir çözüm uygun olduğunda ilişkisel bir veritabanı oluşturmayacaktır, ancak RDBM'ler çok sayıda durumda yararlıdır, bu yüzden nasıl olabilirler bir heves olarak mı değerlendirildi?

— StuperUser
kaynak

1

Lütfen bağlam sağlayın - bu yorumu nerede okudunuz?

— Eran Galperin

8

Her şey ve her şey bir yerde birisi tarafından bir heves olarak kabul edilir.

— Péter Török

Çok doğru Péter, nedenini merak ediyor musun?

— StuperUser

5

Bu tür insanlar genellikle ilişkisel veritabanları fikrine aykırı olan tanıtmak istedikleri başka bir paradigmaya sahiptir. Bu nedenle ilişkisel veritabanları kötüdür ve gitmeleri gerekir. Henüz kritik kütleye ulaşmamış olan nesne yönelimli veritabanlarına bakın.

28

Anahtar, ilişkisel anlamına gelen RDBMS'deki R'dir . Popüler inanışın aksine, tablolar arasındaki ilişkiler değil, her tablonun kelimenin matematiksel anlamında bir ilişki olduğu gerçeği anlamına gelir .

İlişkisel modelin oldukça önemli etkileri vardır. Verilerinizi ilişkilere uyacak şekilde modellemeniz ve bu modeli normalleştirmeniz gerekir . Uygulamanız nesne yönelimli bir model olarak tasarlanmışsa, ilişkisel model uygun değildir. Bu, nesne-ilişkisel empedans uyumsuzluğu olarak bilinir .

Bu uyumsuzluğa bir yaklaşım, çok popülerlik kazanan ORM'lerdir (nesne-ilişki haritacıları). Ama onlar gerçek çözüm değiller, daha çok problem için çalışmak gibi. Sınıf mirasını ilişkisel modele eşleme sorununu hala çözmüyorlar.

Nesne-ilişkisel uyumsuzluğun gerçek çözümü , maalesef çok fazla çekiş elde etmeyen OODBMS'lerdir . OOBD'leri doğal olarak destekleyen popüler motor, hibrit OO / RDBMS olan PostgreSQL'dir. Başka bir OODBMS, Python'da yerleşik olarak bulunan ve tipik kurulumda temel motor olarak RDBMS kullanan Zope Object DB'dir.

Alternatif yaklaşım, uygulama veya orta eşya düzeyinde daha fazla mantığın uygulanması ve temel depolama için NoSQL çözümünün kullanılmasıdır .

Ne OODBMS ne de NoSQL "sadece düz dosya" değildir.

— vartec
kaynak

2

@Daniel: Kesinlikle ilişkisel modelin çözülmesi gereken bir sorun olduğunu söylemedi; tam olarak ne dediğini söyledi - eğer yazılımınızı nesne yönelimli paradigma üzerinde modellemeye kararlıysanız, o zaman ilişkisel model bir problemdir.

— Carson63000

1

@Carson: Özür dilerim, ama cevabı bu şekilde okumadım. @vartec diyor ki: "Gerçek çözüm OODBMS'dir (maalesef çok fazla çekiş bulamadı)." Saygıyla katılmıyorum: Gerçek çözümün ilişkisel modeli anlamak ve etkin bir şekilde kullanmak olduğunu söyleyebilirim. OODBMS, veri modeliniz için OO ilkelerini ne zaman kullanmanız gerektiğine dair zayıf bir çözümdür, ki bu kesinlikle evrensel bir durum değildir.

— Daniel Pryden

1

@Daniel: Ben o bir OODBMS, yine, gerçek çözüm olduğunu sanmıştım eğer sen nesne yönelimli paradigma üzerinde yazılım modelleme için kararlıyız. İlişkisel modelin kendi başına bir sorun olduğu ve OODBMS'nin bunun çözümü olduğu değil. Ama her neyse, hangimiz Vartec'i doğru bir şekilde anlamış olduğumuzu tartışmayacak kadar fazla değil, eğilirim ve isterse açıklığa kavuşturacağım. :-)

— Carson63000

1

@Daniel: Bağlam olduğu önemli. Gerçekten de ilişkisel modelin OOP bağlamında bir sorun olduğunu söylüyorum. Şimdi, OOP ne kadar evrensel ya da değil, bu cevabın kapsamı dışında. Ve btw. OODBMS'ler "fakir insanın çözümü" değildir, ORM'ler.

— vartec

1

@vartec: Tamam, downvote'umu geri çekiyorum. (Gönderi düzenlenmedikçe gerçekten kaldıramıyorum.) OO içermeyen çözümler olduğunu açıklığa kavuşturmanın en iyisi olacağını düşünüyorum. Ve evet, bir ORM'in OODBMS'den bile daha kötü olduğunu kabul ediyorum.

— Daniel Pryden

13

Yukarıdaki soruda alıntıladığınız ifadeyi yaptım. Bu sitedeki geliştiriciler hakkındaki varsayımımı doğrulamak için bir alıntı yapmak istiyorsanız, aşağıdaki soruya cevabımı okuyun ve hala kabul edilebilir bir cevap olarak düşündüğüm için aldığım yorumların ve aşağı oyların geri tepmesini gözden geçirin.

Deneyimli programcılar veritabanı sorgularını bilmeli mi?

Linq veya ORM'ye rağmen bir geliştiricinin SQL hakkında ileri düzeyde bilgi sahibi olması gerektiğini iddia ettim.

Bu, RDBMS'nin MongoDB gibi NoSQL veritabanlarından doğal olarak daha düşük olduğu düşüncesiyle, SQL'in önemi hakkında saygın görüş farklılıkları nedeniyle göründüğü son derece popüler olmayan bir iddiaydı.

DÜZENLEME: İddiamı daha da eklemek için kullanıcı SK-mantığını alıntılayacağım:

sadece tüm bu RDBMS çılgınlığının nispeten yeni bir trend olduğunu unutmayın. Bundan önce çok çeşitli yaklaşımlarımız vardı. Görünüşe göre, yaşınızın geliştiricileri ile birlikte genç bir şirkette çalışıyorsunuz ve böylece eski ve daha sağlam depolama yaklaşımlarına maruz kalma şansınız yok. Neyse ki, bu son eğilim zaten azalıyor ve eski güzel yollar geri dönüyor ve 'nosql' olarak yeniden markalanıyor.

— maple_shaft
kaynak

DB'lerle çalışan geliştiricilerin, bir sorguyu ilişkiler açısından doğru bir şekilde kavramsallaştırmak için SQL'i anlamaları gerektiğini tamamen kabul ediyorum. Ancak, umarım, Linq / ORM'ler soyutlamadaki sorguları, veri deposu ile yazılan sorguları etkileyecek şekilde optimize etmez.

— StuperUser

Herkesin "bu RDBMS çılgınlığı nispeten yeni bir eğilim" demesinin tek nedeni sakallarının ne kadar gri olduğunu göstermektir. İlk olarak 1995'te tanımladığınız kurumsal ve iş uygulamaları üzerinde çalıştım - ilişkisel veritabanları o zamanlar baskındı, şimdi baskınlar, müdahale eden 16 yılda çalıştığım her yere hakim oldular. Açıkçası bazıları kadar yaşlı değilim, ama "nispeten yeni" dediğimde "son yirmi yılda" demek istemiyorum.

— Carson63000

Sorun, birçok geliştiricinin RDBMS'yi yanlış SQL ile eşitlemesidir. SQL, modern standartlara göre gerçekten korkunç bir dildir. Son 30 yılda çok gelişmemiş olan "ilişkisel" bir dilin (SQL gerçekten ilişkisel değildir ve bu sorunun bir parçası) kusursuz ve eksik bir uygulamasıdır. SQL kullanan birçok insan ilişkisel modeli neredeyse hiç anlamaz - tek bildikleri SQL'dir ve bu nedenle ilişkisel modelin hayal kırıklıklarının nedeni olduğunu varsayarlar.

— nvogel

@dportas, Sure SQL mükemmel değil, ama her iş için o kadar önemliydi ki, SQL'de DÜŞÜNMEYE başladığımda hayatın ne kadar kolay olduğunu öğrendim. Bana ilişkisel bir model verirseniz ve bana düz İngilizce bir soru sorarsanız, size SQL'de bir "cevap" yazabilirim. "Bildikleri tek şey SQL'dir ve bu nedenle ilişkisel modelin hayal kırıklıklarının nedeni olduğunu varsayarlar" diyorsunuz, o zaman SQL'i yeterince iyi bilmiyorlar. Neden her zaman en düşük ortak şeytanlara hitap etmeliyiz, zayıf bir eğitim ile 10 $ / saatten daha az kazanan bir Hintli programcı gibi.

— maple_shaft

@maple_shaft, SQL'de düşünüyorsanız, ilişkisel açıdan çok yanlış olan bazı şeyleri düşünüyorsunuz. Teşvik edilmesi gereken, geliştiricilerin, SQL gibi dillere odaklanmak yerine ilişkisel model gibi temel kavramları anlamalarıdır. Daha fazla insan temel kavramları anlasaydı, belki SQL zaten daha iyi şeylerle değiştirilmiş olurdu.

— nvogel

9

fad :

kısa sürede çok popüler hale gelen ve hemen hemen aynı hızda unutulan bir şey. "

RDBMS'ler uzun zamandır varlığını sürdürmektedir (en azından CS terimleriyle), bu yüzden kim demişse başka bir şey söylemek istediğini veya clueless olduğunu söyledi.

— l0b0
kaynak

2

Başka bir şey söylemek istedim, cevabımı aşağıya bakın.

— maple_shaft

Yanıt

3

Muhtemelen urbandictionary yerine gerçek bir sözlük kullanmak daha iyi olurdu.

— Aaronaught

Aaronaught - Princeton'a ne dersin? "Bir ilgi, abartılı gayretle geldi." wordnetweb.princeton.edu/perl/…

— Shauna

3

RDBMS'ye alternatif sadece düz bir dosya değildir. Okuldayken OODBMS yeni bir şeydi ve profesörüm bir heves olarak etiketlediğinde haklıydı. Farklı modellere bir göz atmalı ve trendleri not etmelisiniz . OLAP'a olan güvenin arttığını gördüm ve verileri daha hızlı işleyebilen yeni bir çok boyutlu sisteme bahse girmeye istekliyim.

— Christopher Bibbs
kaynak

"Yeni olmaya istekli" => "yeni bahse girmeye istekli mi?"

— İkili Worrier

Kesinlikle, düz dosya örnek olarak kullanıldı. Bu DB modellerine iyi bir bağlantı.

— StuperUser

@Binary Evet ve bunu yansıtacak şekilde düzenlendi.

— Christopher Bibbs

3

Sorun, birçok geliştiricinin RDBMS'yi yanlış SQL ile eşitlemesidir. SQL, modern standartlara göre gerçekten korkunç bir dildir. Son 30 yılda çok gelişmemiş olan "ilişkisel" bir dilin (SQL gerçekten ilişkisel değildir ve bu sorunun bir parçası) kusursuz ve eksik bir uygulamasıdır. SQL kullanan birçok insan ilişkisel modeli neredeyse hiç anlamaz - tek bildikleri SQL'dir ve bu nedenle ilişkisel modelin hayal kırıklıklarının nedeni olduğunu varsayarlar.

— nvogel
kaynak

1

Bağlam olmadan, RDBM'lerin kimin / neden bir heves olarak kabul edildiğini belirlemek zordur.

Kısa ve orta vadede (5-10 yıl) ve daha da uzağa gitmeyeceğini düşünürdüm. RDBM, müşterilerin / siparişlerin, yolcuların / biletlerin vb. Çoğu şirketin sahip olduğu ilişkisel verilerin depolanması, işlenmesi ve alınması için etkili ve etkili bir yöntem sağlar.

NoSQL gibi, açık kaynak projesiyle nüfus içinde büyüyor gibi görünen başka alternatifler de var.

OLAP olarak bunlar gerçekten (aklımda) bir şirketin bir şirket hakkında zamanında ve faydalı istatistiksel bilgiler vermesine ve mevcut veriler üzerinde "ne olursa olsun" senaryolarını çalıştırmasına izin vermek için tasarlanmış uzman veritabanlarıdır. Tabii ki neredeyse tüm durumlarda bu mevcut veriler bir RDMB'den geldi ve manipüle edildikten sonra OLAP veritabanına yerleştirildi.

— armitage
kaynak

1

İlişkisel veritabanları, mikro hesaplamanın bir heves olduğu anlamında bir hevestir.

— Jeremy
kaynak

1

Basit cevap hayır. RDBMS bir heves değildir. LinqPad için bir web sitesinde bir şey okuduğunuzda, amaçlarının ürünleri için lisans satmak olduğunu unutmayın.

— Tundey
kaynak

Soru, LinqPad'ın tanıtım söylemi değil, neden bir heves olarak kabul edileceği ile ilgilidir. LinqPad standardı ücretsizdir.

— StuperUser

Soru ondan LinqPad'ın tanıtım söylemini okurken geldi. Sadece bir tuz tanesi alması gerektiğine dikkat çekti.

— Tundey

Hayır olmadı, maple_shaft'ın programcılar.stackexchange.com/ questions/89994/… üzerindeki yorumundan geldi . LINQPad kopya edilmiş bir tutam tuz ile çekilen ama Devs ya deyimi ile hemfikir olmadığı konusunda meraklıyım.

— StuperUser

Evet, LinqPad'ın tanıtım söylemi, bir RDBMS'yi sorgulamak için SQL yazmanın eskimiş olmasıydı, RDBMS'lerin kendilerinin eskimiş olduğu değil . RDBMS kullanmanın daha iyi bir yolunu satıyorlar, onlara bir alternatif değil.

— Carson63000

@StuperUser ve Carson63000: Anladım. Benim hatam.

— Tundey

0

Fad uzun, uzun süredir birlikte oldukları için doğru kelime değil. Sanırım teknolojinin çok eski olduğu ve bir sonraki şeyle gelmenin zamanı olabileceği argümanını yapmaya başlayabilirsiniz - belki de NoSQL mimarileri

— bigtang
kaynak

0

Wiki Def. Fad , "fad" terimini şu şekilde tanımlar: Fad , büyük bir popülasyon arasında gelişen ve genellikle davranışın bir şekilde roman olarak algılanmasının bir sonucu olarak bir süre coşkuyla takip edilen herhangi bir davranış biçimidir. Bir hevesin, onu benimseyen insan sayısı hızla artmaya başladığında "yakaladığı" söylenir. Yenilik algısı ortadan kalktığında, davranış normalde hızlı bir şekilde kaybolur.

RDBMS takipçileri hızlı bir şekilde solmadı ve gelecek yıllarda (onu kullanan üretim uygulamalarının büyük yığını sayesinde) ortadan kalkmak üzere olmadığından, bunun bir heves olduğunu söyleyemeyiz. Aslında, RDBMS'nin temel kavramları, diğer birçok teknolojinin dramatik bir şekilde değiştiği (ve hala değiştiği) oldukça sabit kaldı.

RDBMS (ve ana aracı SQL) kavramı, diğerlerinde olduğu gibi, daha iyi olanların yerini alabilecek teknolojide bir adımı temsil ediyor, hepsi bu.

— Şans yok
kaynak