SQLite biraz hafife alınmıyor mu? [kapalı]


15

Soruyu sormadan önce SQLite hakkındaki düşüncelerimi açıklayayım.

Küçük, hızlı ve daha da önemlisi, sadece gerçekten gerekli işlevselliğe sahip araçları seviyorum. Bu yüzden SQLite'yi ve MS-SQL'i biraz daha az seviyorum.

Örneğin: MS-SQL çok daha fazla işlevselliğe, ölçeklenebilirliğe vb. Sahip olabilir, ancak şanssızsanız kurulumu da bir acı olabilir. Tabii ki, zor bir kurulumun belirli bir veritabanını seçmemenin bir nedeni olduğunu söylemiyorum.

Beni yanlış anlama: MS-SQL kaliteli bir üründür. MS-SQL ile çok deneyimliyim; Ürünü bir profesyonel olarak çok iyi anlıyorum. Gerçekten gerekli olmadığı bazı durumlarda daha az tercih ederim (= çok fazla kullanıcı yok, <10-15).

Bir veritabanının işlevselliğinin ne kadarını gerçekten kullanıyorsunuz? Deneyimlerime göre bu genellikle normal SQL'dir (SELECT, INSERT ve UPDATE).

SQLite'yi seviyorum. Büyüleyici hızlı. "Kurulumu" son derece kolaydır. SQLite, iddia edebileceğinden daha fazlasını yapabileceğini düşünüyorum. Neden sadece tek işlem / tek kullanıcı uygulamaları için kullanılır? Sonuçta: pek çok uygulama sürekli bir veritabanına erişmiyor.

Örneğin: 15 kullanıcılı bir ERP uygulaması düşünün. SQLite neden bunun için kullanılamıyor? Kabul edelim: mesleki deneyimimde, çoğu zaman bu tür bir uygulamanın kullanıcıları, uygulamayı kullandıkları toplam sürenin yaklaşık% 5-10'u için veritabanına erişeceklerdir. Diğer% 90-95'te ise sadece ekrandaki bilgileri izliyor, veriyi bir ızgaraya / forma giriyor ve girişlerini kaydettiklerinde veritabanı süresinin 1 saniyeden fazla değil. Fe: 1,5 dakikalık giriş süresi ile 1 saniyelik tasarruf süresi.

SQLite veritabanı dosyası "zamandan tasarruf" sırasında kilitlenirse, veritabanına erişmesi gereken diğer kullanıcılar beklemekle birlikte beklemezler, çünkü bekleme süresi çok küçük olacaktır (fark edilmez). Kodda, istisnaları önlemek için veritabanının olası "meşgul" zamanıyla uğraşmak zorundasınız, ancak bunu yapmak zor değil.

Benim gibi aynı düşünmesi gereken bazı adamlar, SQLite: SQLitening için bir istemci-sunucu çözümü bile geliştirdi . Bu beni kendimi kandırmayacağım konusunda daha ikna etti.

Tabii ki SQLite sığmayan veritabanı yoğun uygulamalar vardır. Ama şimdi düşündüğüm gibi, çok kullanıcılı birçok uygulama, 15 kullanıcıyı aşmıyorsa, SQLite ile iyi çalışmalıdır.

Müşterilerimizin çoğu donanıma fazla para harcamaz, bu yüzden genellikle üzerinde her şey (Exchange, SQL (ler), istemciler, vb.) İle tek bir sunucu ile karşılaşıyorum ve bu nedenle neredeyse "nefes nefese". Yüksek sistem gereksinimleri olmayan bir ürün teslim edebilseydim, müşterim mutlu olurdu. SQLite herhangi bir ağırlık eklemez (en azından fazla değil), MS-SQL ekler. Bu yüzden SQLite'ı seçmem, çünkü ücretsiz, ucuz veya kurulumu kolaydır. Pratik / teknik nedenlerden dolayı seçerdim.

FYI: Mesleğimde, müşterilere ortalama olarak en fazla 5-6 kişinin ürünü kullanacağı ürünler (özel ve standart, çoğunlukla ERP ile ilgili) satıyoruz. Bazı istisnalar vardır, ancak en fazla 10-15 kullanıcı vardır.

Soru: Açıkladığım örnek gibi çok kullanıcılı bir uygulama için SQLite kullanabileceğimi düşünüyor muyum? Bilmem gereken herhangi bir teknik dezavantaj var mı? Doğru seçimi yapmama yardımcı olacak deneyimleriniz (olumsuz veya olumlu) nelerdir?

Güncelleme: Lütfen bunu diğer veritabanlarının olumsuz bir yargısı olarak görmeyin. Çoğunlukla iyi ürünlerdir. Sadece düşüncelerimi burada paylaşıyorum ve bu konudaki görüşlerinizle ilgileniyorum.


9
Maalesef, "Haklı mıyım?" rant'ı bir soruya dönüştürmez.
pdr

1
@pdr: Bunu neden bir rant olarak düşünüyorsun? MS-SQL veya diğer veritabanlarını olumsuz değerlendirmiyorum; çoğunlukla hepsi iyi ürünlerdir. Sadece düşüncelerimi paylaşıyorum ve diğer programcıların görüşlerini duymakla ilgileniyorum. Ne fazla ne eksik.

3
Orada soru yok, sadece doğrulama arayışı var. SSS bölümünden: "Yalnızca karşılaştığınız gerçek sorunlara dayanarak pratik ve cevaplanabilir sorular sormalısınız. Konuşkan, açık uçlu sorular sitemizin kullanışlılığını azaltır ve diğer soruları ön sayfadan çıkarır." programmers.stackexchange.com/faq
pdr

1
@pdr: Bunu anlıyorum, ama dürüstçe burada bir soru sormak istedim. Belki net değildim, bu yüzden soruyu yeniden ifade ettim.

4
Veritabanı seçimi, kod optimizasyonu, istemci, sunucu veya web tabanlı uygulama, bunların tümü dikkate alınan alanlardır ve artıları ve eksileri böyle bir platformda tartışılmalıdır. Benim için rant daha çok, birisi belirli bir teknolojide herhangi bir kalite kullanmayı kategorik olarak reddettiğinde daha fazladır.
JeffO

Yanıtlar:


8

SQLite'ın bol olduğu birçok örnek vardır. Kullanıcı, departman veya şirket nadiren aşırıya kaçar (Uygulama iyi çalışıyorsa kimse programcı çağırmaz çünkü o kadar fazla duymuyoruz.) Bir MS Access dosyası (Windows) veya SQL Server Compact Edition (bazı kurulum gerekir). Hepsi yerel bir uygulama için yeterince iyi çünkü dosyanın güvenliği konusunda endişelenmenize gerek yok.

Yerel ağdaki çok kullanıcılı bir senaryoda, dosya tüm kullanıcıların erişmesi gereken paylaşılan bir klasöre gidiyor - çağrı güvenliği. Basit bakım veya yedeklemeler veya sütun ekleme gibi herhangi bir tablo yapısı değişikliği, diğer kullanıcıların erişmesini engelleyecektir. Dün gece yedekleme işe yaramadı çünkü birisi uygulamadan çıkmayı unuttu. Gün ortasında bir yedekleme yapmak istediğinizde ne olur? Herkes, veritabanlarının teknik sınırlamaları nedeniyle gün boyunca herhangi bir yedeklemeye ihtiyaç duymadığını rasyonelleştirir. Bir noktada, sunucunuza SQL Server Express / diğer eşdeğerini yüklemek bazı ilk kurulum ve güvenlik yapılandırmasını alacaktır, ön tarafta daha fazla yer alır, ancak çok az bakım gerekecektir.

Ölçeklenebilirlik / aşırı mühendislik konusunda her zaman endişe vardır. Kullanıcı sayısı veya veri miktarı hala yönetilebilir olsa bile, birisinin her zaman canlı verileri bazı intranet veya diğer web sitesi / tarayıcı arayüzünde kullanma fikri vardır. Dosya veritabanlarında sorunlar var. Veri dosyasına bir VPN üzerinden erişmek isteyen bir kişi (uygulama dizüstü bilgisayarına kurulur) size bir 'ölçeklendirme' sorunu verir. Uygulamayı, döndüklerinde senkronizasyon yapabilen bağlantısı kesilmiş kullanıcılara izin verecek şekilde oluşturabilirsiniz. Sadece ara sıra ofis kullanıcısı için buna değmez.


Aynı argümanı SQL Server Compact Edition için de yapabilirsiniz, ancak MS Access veritabanı için değil . Access veritabanlarına gerçek bir veritabanı gibi davranılır, ancak paylaşılan dosyalar gibi çalışır. Kırılgan bir çözümdür; SQL Server Compact aslında Access ön uçlarıyla çalışan daha iyi, daha hızlı, daha güvenilir bir alternatiftir. Teknik olarak paylaşılan bir dosya çözümü olmasına rağmen SQLite'ın Access veritabanından önemli ölçüde daha dayanıklı olduğundan şüpheleniyorum.
Robert Harvey

@RobertHarvey - MS Access'in 10 yıldır yeterince iyi (yani Excel'den daha iyi) bir çözüm olduğu iş taleplerimiz var. Büyük bir anlaşma yapıldığında, bir şeyler hazır ve çalışır durumda olmalı. Erişim becerisine sahip güçlü kullanıcıları bulmak ve kullanmak çok daha kolaydır. İşlevselliğin belirli bir tarihte olması gerekir, ancak ölçeklenebilirlik, performans, veri büyümesi ve güvenliğin hiçbir zaman bir faktör olmadığı için şanslıyız. Access'i yükseltmek, şimdi farklı bir hikaye.
JeffO

Beni yanlış anlamayın; Bence Access harika. Ancak SQL Server Compact, kullanıcıların veri paylaştığı tüm yeni Access uygulamaları için minimum arka uç gereksinimim olacaktır.
Robert Harvey

@RobertHarvey - Buna bakmam gerekecek. Teşekkürler
JeffO

12

"Dahili" bir veritabanına ihtiyacınız olduğunda kullanmak harika olduğunu düşünüyorum. Yani, uygulamanızın / kodunuzun etkileşime gireceği ancak uygulamanızın varlığının ana nedeni ile doğrudan ilişkili olmayacak bir veritabanı. Büyük bellek içi eşlemeler veya önbellek yöneticileri kullanmak yerine, örneğin böyle bir veritabanını da kullanabilirsiniz. Son zamanlarda bir veritabanına bağlanmak, bazı iş yapmak, veri okumak ve sonunda her şeyi silmek için gereken JUnit / DBunit test durumlarda kullandığım gibi bunun çok somut bir örneği var. Veritabanını oluşturmak için yalnızca boş bir dosya oluşturmanız gerektiğinden, bunu yapmak oldukça kolaydı.

Gördüğüm başka bir kullanım: sadece bir kullanıcınız olduğunda. Evet, bu mümkün, örneğin "Firefox" veya "Opera" yı düşünün :-)

Ayrıca, SQLite web sitesinde bu konuda çok dürüst ve BT KULLANMAMAK için nedenler veriyorlar ("Başka Bir RDBMS'nin Daha İyi Çalışabileceği Durumlar" paragrafına bakın)

ps: Sql Server Express üzerindeki yorumlar ile ilgili, evet "yüklü" olması gerekiyor. Ve kişisel güncelleme bazı sorun vardı (2008 R2 yüklemek için manuel olarak önceki sürümle ilgili bazı kayıt defteri anahtarlarını kaldırmak zorunda kaldı). Ancak, SQLite'ı Microsoft tarafından geliştirilen bir veritabanıyla karşılaştırmak istiyorsanız , yüklemeniz gerekmeyen Sql Server Compact Edition'a bakın (bkz. "Özel dosya tabanlı dağıtım").


CE'ye baktım, ama bir şekilde SQLite daha iyi / daha hızlı / daha kolay görünüyor. Emin değilim, emin olmak için yeterince CE kullanmadım / test ettim.

5

Örneğin: 15 kullanıcılı bir ERP uygulaması düşünün. SQLite neden bunun için kullanılamıyor?

Çok az uygulamada bu kadar az kullanıcı vardır. Ve daha fazla kullanıcı ve daha karmaşık veri manipülasyonu gören herhangi bir şey için, SQLite kullanımı, basit "tek seferde bir yazma işlemi" kilitleme modelinden dolayı performans nedenleriyle tamamen söz konusu değildir.

Diyelim ki, her biri 60 saniye boyunca bir form doldurup göndererek çalışan 100 kullanıcınız var. Yani saniyede yaklaşık 1,6 işlem yapmanız gerekiyor. Veri modeli karmaşıktır ve bir formun kaydedilmesi birçok büyük tablodan okuma ve yazmayı, hatta belki de farklı bir sistemle iletişim kurmayı içerir, bu nedenle her "form gönderme" 2 saniye süren bir işlemle sonuçlanır. Ancak SQLite işlemleri aynı anda işleyemez, bu da scond başına sadece 0,5 işlemi işleyebileceği anlamına gelir. Hata.

"Kurulumu bir acı olabilir" kritik bir altyapıya karşı karar vermek için iyi bir neden değildir. Ayrıca, en az ikisi (MySQL ve Postgres) ücretsiz olan ve SQLite'nin eşzamanlılık sınırlamalarına sahip olmayan seçim yapabileceğiniz başka DB motorları da vardır. Kurulumu MS-SQL'den bile daha kolay olabilir.


Anlıyorum ve katılıyorum. Ancak mesleğimde ürünlerimizi (standart ve özel, çoğunlukla ERP ile ilgili) 10'dan fazla kişiyle kullanan müşterilerim yok. Ortalama 5-6 kullanıcı bile var. Sorumu yeniden ifade edeceğim.

4
@Marcus V: Soru şu: Eğer bir müşteri çok büyüdüyse ve oluşturduğunuz uygulamanın kullanımı inanılmaz derecede yavaşladığını fark ederse ve onlara bunun nedenini DBMS'nin birçok kullanıcıyı işleyemeyeceği ve " neden daha iyi bir DBMS kullanmadınız "diye sorduğunuzda," bunların kurulumu zordur "cevabının nasıl alınacağını düşünüyorsunuz? Size tepkimin ne olacağını söyleyebilirim: "Bu bir amatör. Yazılımımı yazmak için başka birini bulmam gerek" diye düşünürdüm.
Michael Borgwardt

Haklısın. Bu şekilde kastettiğini sanmıyorum ama amatör olmadığımı garanti edebilirim. Durum isterse kesinlikle kullanıcı "gerçek" DBMS sistemleri olacaktır. Ürünlerimiz bir dizi kullanıcı için lisanslanmıştır. Yalnızca kullanıcı sayısının nispeten az olduğunu bildiğimde SQLite kullanarak gelişirim (<10-15). Müşteri, yakında müşteri tabanımızda gerçekleşmeyecek bir sınırı aşacaksa, bunları her zaman nispeten hızlı / basit bir şekilde başka bir veritabanına dönüştürebiliriz. Bu roket bilimi değil;). Yorumlarınıza dayanarak, soruyu daha açık hale getirmek için yeniden ifade ettim.

Uygulamanın dışına çıkması konusunda faul ağlayan kullanıcı muhtemelen kullanıcı sınırlamaları hakkında bilgilendirildi, ancak daha ucuz bir rota seçti. Başlangıç ​​kurulumunda her şey yolunda, ancak yeni sunucuya yüklemek için başka bir ücret talep etmeniz gerektiğinde, bir dosyayı kopyalayabilecekleri zaman ne kadar mutlu olacaklar?
JeffO

1
@ Jeff O: Sanırım niyetlerimi yanlış anladın. Ben ediyorum değil ve / veya kolay kurulumu ücretsiz, ucuz olduğu için SQLite seçmek. Sadece küçük, hızlı ve kaynak dostu olduğu için seçerdim. Yani pratik / teknik nedenlerle. Müşterilerimizin çoğu donanıma fazla para harcamaz, bu yüzden genellikle üzerinde her şey (Exchange, SQL, vb.) İle tek bir sunucu ile karşılaşıyorum ve bu nedenle neredeyse "nefes nefese". Yüksek sistem gereksinimleri olmayan bir ürün teslim edebilseydim, müşterim mutlu olurdu. SQLite herhangi bir ağırlık eklemez, MSSQL ekler.

4

SQLLite'ın uygulama geliştirme için mükemmel olduğunu düşünüyorum, en büyük gücü istemcide kurulmasına gerek olmamasıdır.

Bununla birlikte, SQL Server Express'i de hafife almayın, sıradan sql sunucusunun özelliklerinin çoğuna sahip, veritabanı boyutunda (aşılması zor) sadece bir sınırlama ile birlikte ücretsiz mükemmel bir veritabanıdır. SQL Server.

En büyük dezavantajı afaik, onu yüklemeniz gerektiğidir, ancak o bölümden biraz emin değilim, şimdi bir yol olabilir


2
Haklısın. MS-SQL Express kaliteli bir üründür. Sadece biraz şişkin ve çok fazla kaynak kullanıyorum. Günümüzde PC / sunucularda sorun değil. Daha güçlü bir donanımın hala önleyebileceğim kaynakları ihmal etmem / israf etmem gerektiği anlamına gelmediğini düşünen adil ve eski okul insanıyım. Daha az daha iyi ...;).

2
DB motorlu veritabanı, disklerden okuma / yazma yerine belleği önbelleğe alarak erişimi optimize edebilir. Ama SQL Lite gibi süreç içi DB için performans hakkında emin değilim
sarat

1
@sarat: Afaik SQLite bellek önbelleklerini yoğun bir şekilde kullanıyor.

2

Her saat birkaç GB veri ile uğraşıyorsanız SQLite'yi ciddi bir veritabanı olarak görmüyorum. Acı verici bir şekilde yavaşlar ve tüm Uygulamanın performansını düşürür. Üzgünüm, ama SQLite için hayranlığınızı kabul etmiyorum :-)


1
Sana saygı duyuyorum. Ben sadece pratik bir adamım. Bir araç seçtiğimde seçiyorum çünkü en gerçekçi / pratik karar olduğunu düşünüyorum. Ben SQLite ile hayran değilim, ama böyle küçük, verimli ve hızlı bir pakette çok koymak başardı şekilde hayranım. Sorumda belirttiğim gibi: MS-SQL belirli bir iş için daha iyi bir araçsa, bunu seçerim. Ancak, açıkladığım gibi, birçok durumda SQLite'nin sadece uygun olduğuna gerçekten inanıyorum.

Veri kullanımı bu büyük bir if.
JeffO

@ Jeff O: Doğru. Yalnızca kullanıcı sayısı nispeten düşükse (<10-15) ve toplam veri miktarı yüksek değilse SQLite'yi seçerim. Deneyimlerimize göre, toplam veritabanı boyutu genellikle 300-400MB ve neredeyse hiç> 1GB'dir.

1

Veritabanlarındaki sorun, gittikçe daha fazla veri toplama eğiliminde olmalarıdır. Hafif bir DB seçmek, aracınızın düzgün ölçeklenmemesi riskini doğurur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.