Ne zaman bir metin dosyasından veri ayrıştırmak yerine veritabanı kullanımı tercih edilmelidir?


13

Kod görüntülemenin büyümesini ölçmek için bir Python programı yapıyordum . Yaklaşımım, ön sayfada gösterilen "Site istatistikleri" ni almak ve bunları sabit diskime kaydetmekti. Bunu her gün bir kez yapmayı planlıyorum. Şimdiye kadar istatistikleri almak ve bir metin dosyasına eklemek için yeterli yaptım. Python betiği github'da görüntülenebilir . Kullandığım biçim şu

22-08-2013

questions 9073
answers 15326
answered 88
users 26102
visitors/day 7407

22-08-2013

questions 9073
answers 15326
answered 88
users 26102
visitors/day 7407

Dosyada kullanacağım formatı almak için betiği iki kez çalıştırdım. Başlangıçta bu benim için iyi görünüyordu çünkü onu kendim saklıyordum ve format aynı olacaktı, bu yüzden kolayca ayrıştırılacaktı ama emin değilim. Veritabanını kullanmak burada daha iyi olmalı, çünkü bu şekilde veri almak daha kolay olmalı. Sadece bir not, hiç bir veritabanı kullanmadım ve SQL, MySQL veya RDBMS'nin diğer varyantları hakkında hiçbir bilgim yok.

Bu da beni soruya getiriyor. Verileri bir metin dosyasında depolamak için veri tabanı ne zaman tercih edilmelidir? Bir veritabanına veya basit metin dosyalarına ihtiyacım olup olmadığına karar verirken arayabileceğim bazı işaretçiler var mı?

Not: Daha iyi etiketler eklenebilirse lütfen bunu yapın. Eklenebilecek etiketler hakkında bazı şüphelerim vardı.


"Nasıl kullanılacağını öğrenene kadar her araç bir yükümlülüktür."
JeffO

1
Bir veritabanı projeniz için uygun olabilir veya olmayabilir. Bununla birlikte, daha basit bir format kullanmanın yararlı olacağını görebilirsiniz. Python ile standart olarak kullanmayı düşünebileceğiniz bir CSV modülü var. CSV'ye sahip olmak, verileri diğer programlara aktarmayı basitleştirecektir (örneğin, grafik olarak gösterebilmek için bir e-tabloya).
Sean McSomething

Yanıtlar:


14

Verileri bir metin dosyasında depolamak için veri tabanı ne zaman tercih edilmelidir?

Wikipedia bize bir veritabanının organize bir veri koleksiyonu olduğunu söyler . O tedbir olarak, metin dosyası olan bir veritabanı. Söylemeye devam ediyor:

Veriler tipik olarak gerçekliğin ilgili yönlerini bu bilgiyi gerektiren süreçleri destekleyecek şekilde modellemek için düzenlenir. Örneğin, otellerde oda müsaitliğinin, boş bir otel bulmayı destekleyecek şekilde modellenmesi.

Bu bölüm sübjektiftir - bize özellikle verilerin nasıl modellenmesi gerektiğini veya hangi işlemlerin optimize edilmesi gerektiğini söylemez. Metin dosyanız her gün bir tane olmak üzere bir dizi ayrı kayıttan oluşur, bu nedenle gerçekliğin bir yönünü sorununuzla ilgili bir şekilde modellenirsiniz.

"Veritabanı" derken muhtemelen bir tür ilişkisel veritabanı yönetim sistemi düşünüyorsunuz, ancak metin dosyanızı veritabanı olarak düşünmenin sorunuzu "ne zaman bir veritabanı kullanmalıyım?" "Ne tür bir veritabanı kullanmalıyım?" Bu ışıkta bir şeyler görmek cevabı görmeyi kolaylaştırır: Sahip olduğunuz veri artık gereksinimlerinizi karşılamadığında daha iyi bir veritabanı kullanın.

Python betiğiniz ve basit metin dosyanız yeterince iyi çalışıyorsa, değiştirmenize gerek yoktur. Günde sadece bir yeni kayıt ve bilgisayarların her yıl daha hızlı hale gelmesiyle, mevcut çözümünüzün uzun süre geçerli olabileceğinden şüpheleniyorum. On yıllık veri, size yalnızca bir kez ayrıştırıldığında 75 kilobayttan daha azını gerektiren 3650 kayıt verecektir.

Günde bir küçük kayıt yerine, CodeReview'da sorulan her soruyu, kimin ne zaman ve ne zaman kaydetmeye karar verdiğinizi düşünün. Ayrıca, tüm yanıtları ve ilgili meta verileri de toplarsınız. Sen olabilir bir metin dosyasına tüm depolamak, ancak bir düz dosya bunu gerektiğinde zor bilgileri bulmak mümkün kılacaktır. Her şeyi belleğe okumak için çok fazla veri olurdu, bu yüzden bir soru veya cevap bulmak istediğinizde, aradığınızı bulana kadar dosyayı taramanız gerekir. Belirli bir kullanıcı tarafından sorulan tüm soruları bulmak istediğinizde, tüm dosyayı taramanız gerekir. Etiket olarak "hata" içeren tüm soruları bulmak isterseniz, dosyayı taramanız gerekir.

Bu çok yavaş olurdu, bu nedenle belirli bir kaydı bulmak için dosyaya nerede bakacağınızı söyleyen bazı dizinler oluşturarak işleri hızlandırmaya karar verebilirsiniz. Sorular için bir endeksiniz, kullanıcılar için bir başkası, cevaplar için bir üçüncü vb. Olabilir. Bir soru bulmak istediğinizde (çok daha küçük) soru dizininde arama yaparsınız, sorunun ana veri dosyasındaki konumunu alır ve hızlı bir şekilde dosyadaki doğru noktaya atlarsınız. Bu büyük bir performans artışı olacaktır. Gerçekten de, bir veritabanı yönetim sistemi budur.

Bu nedenle, ihtiyacınız olan şey olduğunda bir DBMS kullanın. Çok fazla veriniz olduğunda, bu verilere hızlı bir şekilde ve belki de başlangıçta tamamen tahmin edemeyeceğiniz şekillerde erişebilmeniz gerektiğinde kullanın. Birbirine bağlı farklı veri türleriniz - farklı kayıt türleri - varsa , çeşitli kayıtları uygun şekilde ilişkilendirebilmeniz için bir RDBMS kullanın .


3
"metin dosyası bir veritabanı değişiklikleri olarak düşünme" Çok anlayışlı. Ayrıca benim hakkımda sadece 3650 girişleri olan kısmı yardımcı oldu. Sorunun gerçek bir perspektifini elde etmeye yardımcı oldu.
Aseem Bansal

1
Son derece hafife alınan cevap, ikinci kez ona geri döndüm.
Hashim

6

Veri tabanlarının birçok avantajı vardır, ancak erişimi kolaylaştırmak bunlardan biri değildir. Daha hızlı, daha standartlaştırılmış, gömülü komut alt dili olarak yorumlanabilir, daha güvenli, evet - ama daha kolay değil. Dilinizin ve standart kütüphanenizin ne kadar sözdizimsel şekeri olursa olsun, ilk etapta bir veri tabanına sahip olmanız, ona bir bağlantı açmanız ve programınızdaki verileri tamamen farklı ve geri bir şekilde yönlendirmeniz gerekir. Yaptıklarınızla ilgili herhangi bir sorun olmadığı ve programlama kolaylığı sizin önceliğiniz olduğu sürece, sadece "iyi uygulama" olduğunu düşündüğünüz için asla veritabanına geçmeyin.

Ne zaman geçiş yapacağımı benimsemem tarihsel gelişmeyi takip etmektir. Sonuçta, insanlar ilişkisel DB icat edilmeden önce uzun bir süre dosyalarda veri depoladılar ve aslında daha önce bir sürü alt veritabanı modeli (hiyerarşik DB, ağ DB ...) icat edildi. Veri tabanları yazmaya başladılar ve bunun büyük işlem çabalarından tasarruf edeceği, güvenilirliği vb. Genel olarak ve uzun vadede artıracağı netleştiklerinde kullandılar . Sizin için durum böyle olmadığı sürece ve yakın zamanda durumun böyle olacağını öngörmüyorsanız, geçiş aşırı mühendislik olacaktır.


Tutarlılık genel tasarıma göre daha iyi sunulmuyor mu? örneğin benim durumumda her tarihe karşılık gelen 5 değer saklıyorum. Mevcut durumda veriler arasında bir uyumluluk yoktur.
Aseem Bansal

Haklısınız, tüm kayıtların tutarlı bir alan ve değer kümesine sahip olmasını sağlamak bu avantajlardan bir diğeri. (Kesin olarak konuşmak gerekirse, sadece ilişkisel veri tabanlarıdır. İnsanlar üretimde uzun süre ilişkisel olmayan veri tabanları kullandılar ve şu anda "NoSQL" hareketi ile tekrar çekiş yapıyorlar.)
Kilian Foth

3

Bu elbette bir yargılama çağrısı olacaktır, ancak dikkate alacağım üç ana kriter şunlardır: ACID uyumlu olması, verilerin ne kadar karmaşık olması ve son olarak kaç şeyin okunması / yazılması gerekiyor? Basitçe bir satır okuyup yazdığınız ve uygulamanız okuma ya da yazma yapan tek uygulama olduğu sürece, muhtemelen veritabanını atlayabilirsiniz. Okuma veya yazma için birden fazla uygulamaya sahip olduğunuzda veya veri yapınız karmaşıklaştığında (özellikle ayrı satırlar arasında ilişkileri varsa) bir DB gerçekten çekici görünmeye başlar.


"kaç şey okumak / yazmak gerekiyor" - Bu yardımcı oldu.
Aseem Bansal

2

Veritabanları sadece verileri depolamak için değil, verileri işlemek ve sorgulamak için de kullanılır, bu nedenle eğitimli bir karar vermeniz gerekir:

Büyük bir faktör, makineye bir veritabanı kurmanın getirdiği işlevsellik vs

Açıkçası, verileri sorgulamanız ve işlemeniz gerekiyorsa ve erişimin hızlı olmasını istiyorsanız - ve ayrıca diğer işlevler için bir veritabanı kullanmayı düşünüyor olabilirsiniz, o zaman iyi bir fikir olabilir. Veritabanları depolama modelleri, verilerin önemli değerlerle çok hızlı bir şekilde aranmasına izin verir ve bir dosyayı ayrıştırma işleminin yavaş olabileceğini düşünebilirim (nasıl yaptığınıza bağlı olarak)

SQL ile bir oyun oynamak ve neler yapabileceğini istiyorsanız, SQLFiddle.com ile oynayabileceğiniz birkaç farklı RDBMS modeli vardır (sorguları çalıştırın, şema oluşturun vb.)


Python için yerleşik bir standart kütüphane arayüzüne sahiptir sqlite3. Bu yüzden bir veritabanı kurmak sorun değil. Benim düşüncem, veri depolamaya devam edersem, bir çeşit indeksleme yapmadıkça yavaşlayabilir. Bir veritabanı bununla ilgilenebilir diye düşünüyorum. Bunu öğrenmek için sqlite3'ü ayrı indirdim, bir veritabanı kullanmadan önce veritabanı modelleri hakkında bilgi edinmem gerektiğini keşfettim. İnternet tabanlı örnekleri kullanarak sqlite3 öğrenebilirim ama şu anda veritabanı modellerini öğrenmekte sorun yaşıyorum. Sonra zahmete değse bile aklıma geldi mi?
Aseem Bansal

2

Her zaman olduğu gibi bir veritabanı kullanmak ya da olmamak ne yapmanız gerektiğine bağlıdır. Büyük miktarda veriye sahipseniz ve üzerinde birçok farklı sorgu yapmanız gerekiyorsa, muhtemelen bir veritabanı size yardımcı olabilir.

Sizin durumunuzda, performansı kabul edilinceye kadar depolamayı bir test dosyasında tutardım. Genellikle bir metin dosyasını okumak (büyük bile olsa) bu kadar uzun sürmez. Daha fazlasına ihtiyacınız varsa, veritabanını her zaman daha sonra ekleyebilirsiniz.

Deneyimlerime göre, veritabanlarında tamamen yeniyseniz, sqd olmayan couchdb: http://couchdb.apache.org/ gibi bir şeyi kullanarak daha kolay bulabilirsiniz ve sorgular için doğrudan javascript veya python vb. Kullanabilirsiniz.

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.