Depolama biçimleri arasında nasıl karar verilir ve bazıları için örnek kullanım örnekleri nelerdir?


10

Program verilerini depolamanın farklı yolları var (dosyaları oyunlara, çalışan veritabanlarına, program yapılandırmasına vb. Kaydedin):

  • Düz metin (düşün .inive .conf)
  • XML
  • Veritabanları (MySQL, SQLite ...)
  • .zip ve birkaç dosya içeren benzeri (farklı formatlarda)
  • İkili dosyalar ( .docörneğin serileştirme aracı tarafından oluşturulan vb.)

Yukarıda listelenen formatlar için farklı kullanım durumları nelerdir ve avantajları kontra dezavantajlara sahiptir (düşünme hızı, esneklik, dosya boyutu, kullanım kolaylığı ...)? Farklı görevler için aralarında nasıl karar verilir?

Sıkıştırma formatı hakkında: Bu sadece diğer dosyaları içermek için kullanılır. Başka bir sıkıştırma formatı da olabilir. Bu, görüntü dosyaları, ses dosyaları ve metin dosyaları dahil olmak üzere birçok dosyanın yapısına izin verir. Örnek olarak, iletiler için dosya içerebilecek bir depolama biçiminiz olduğunu varsayalım. Sıkıştırılmış bir dosyanın içinde aşağıdaki dosyalar olabilir:

message.txt (containing the message)
attachments (folder containing attachments)
  audio.wav
  picture.jpg

wrt ikili, Google Protokol Tamponu düşünün. Tembel serileştirme yeteneği harika ve her zaman onu ayıklama ve biçimlendirilmiş metin olarak yeniden kaydetme olanağına sahipsiniz (birkaç dilde C ++ / Java / Python).
Matthieu M.Nis

Yanıtlar:


6

Aşağıdaki gibi kullanıyorum:

Düz metin

Konfigürasyon için - genellikle YAML veya .ini kullanılır. Bir metin dosyasının istenen sonuç olmadığı durumlar haricinde çoğu kullanım için kullanımımdan kaldırılmıştır (örn. Metne yazdırma, metne kaydetme vb.)

XML

Verilerin yapılandırılması ve taşınması için; örneğin, dışa aktarma, XSLT aracılığıyla format vb. Taşınabilir dosya formatı olarak iyi (örn. SVG). Mükemmel manipülasyon araçları ve filtreleri.

Veritabanları

Uygulama / webapp içinden ana veri depolama. İstediğiniz zaman depolama alanı olarak kullanın. Güvenilir, sağlam ve yerleşik bir çok şey elde edersiniz (işlemler, referans bütünlüğü, basamaklı silme / güncelleme, dizinler, hız). En iyi katman veya ORM (IMO) ile kullanılır.

Tek dosya arşivi (örneğin .zip)

İlgili çoklu ikili akışları kompakt bir şekilde saklamak için uygundur, örneğin bir emülatör için ROM görüntüleri. Sık sık güncellenmesi veya hiç güncellenmesi gerekmeyen şeyler için en iyisi. Ağır, yavaş ve manipüle edilmesi zor;

İkili

Yalnızca veritabanının uygulama verilerini depolamak için kullanılamadığı yerlerde. Serileştirme ile en kolay (C ++). Yüksek derecede ayarlanmış bir ikili format, hız ve boyut için diğer her şeyden daha iyi performans gösterecektir.


4

Gümüş mermi yok. Tecrübelerime göre:

Depolama ortamı olarak düz metin otomatik bir no. Birkaç durumda daha iyi bir şema ve tip güvenliği var .config dosyası tarafından ele alınacağını düşünürdüm. Görünüşe göre tip güvenliği ve veri çıkarma ihtiyacı neredeyse her zaman karşımıza çıkıyor. Düz metin bu işlemi bir kabus yapar.

XML : Tip güvenliği, veri doğrulama, düşük hacimli ve bazı durumlarda .NET'in nesnelerin XML serileştirmesi için güçlü bir destek sağladığı için kullanıyorum.

Veritabanları : Varsayılanım. Güvenlik, hız, işlemler, iyi güvenilir ve plana göre bir şey gitmezse bir depolama ortamı olarak bir DB seçmek için suçlanmak zor yazın.

.zip bir sıkıştırma biçimidir, bunun nasıl devam ettiğinden emin değil misiniz?

İkili : İkili dosyayı yalnızca geçici bir bellek akışı oluşturmam gerektiğinde kullanıyorum. İkili, verilerimin şema ile organize edildiği bir DB veya XML ile karşılaştırıldığında sorgu yeteneği yolunda değer katmaz.

Kullanım kolaylığı görecelidir ve özellikle neyi başarmak istediğinize bağlıdır. Hacim ile ilgili yukarıda söylediğim şeyin dışında hız benzer. Dosya boyutu bir endişe ve uygun normalleştirme uygulanırsa, zip veya başka bir sıkıştırma formatı ile sıkıştıracağım, ancak bu ayrı bir işlemdir.


3

Bunları aşağıdaki gibi kullanıyorum:

Düz Metin

Bu kategori YAML veya özellikler dosyaları gibi biraz daha ayrıntılı formatlar içeriyorsa, insanların elle okumasını ve düzenlemesini beklediğiniz her şey için en iyi seçenektir. Bir başka büyük avantaj, küçük bir komut dosyası (örn. Sed) aracılığıyla değiştirmenin basitliğidir.

Hiçbir şey basitliği ve kullanım kolaylığını aşamaz. Destek ekibinin uzak makinede bir şey yapılandırması gerektiğinde (örneğin, bir müşterinin sorununu çözdüğünde) veya BT'nin yazılımınızı çalıştıran bir grup sunucuyu yeniden yapılandırması gerektiğinde, bu biçimi seçtiğiniz için teşekkür ederler. Ayrıca, bunu onlar için yapan bir kerelik bir yazılım yazmaktan kurtaracaktır.

XML

Burada @Ingo ile hemfikirim - düz metin XML'in aksine komut dosyası ile işlenmesi daha zor ve el imo ile düzenlemek için bir kabus.

Yine de, YAML'nin çözülemez hale geldiği ve yine de insan tarafından okunabilir ve düzenlenebilir olmasını istediği ayrıntılı bir yapıya sahip verileriniz varsa, XML muhtemelen en iyi seçimdir.

İlişkisel veritabanı

Üçüncü tarafların SQL komutları ve hatta GUI'ler aracılığıyla manuel olarak düzenlemelerine izin vermek isteyebileceğiniz çok sayıda veri (düz metin ve XML hantal hale getirecek) olduğunda mükemmel bir seçim.

Diğer bir avantajı, içeriği yöneten kodunuzun çok okunabilir olmasıdır. @ Richard-Harrison mükemmel cevabında diğer avantajların iyi bir listesini verdi.

NoSQL Veritabanı

RDBMS'ye göre bir avantaj, muhtemelen sorunuzla çok ilgili olmayan dağıtım yoluyla ölçeklenebilirliktir. Muhtemelen daha alakalı olan avantajlar, bir anahtar-değer deposunun basitliği ve şematikliğin esnekliğidir (bu bir kelime midir?). Kendinizi ilişkisel paradigmayı kırdığınızda bulduğunuzda: blobları veritabanına depolamak, anahtarla erişmek ve kod aracılığıyla işlemek, sonra bu seçeneği göz önünde bulundurun. Bazı seçenekler (örn. CouchDB) çok portatiftir, az yer kaplar ve ölçeklenebilir, böylece MySQL ve SQLite için iyi ilişkisel olmayan bir alternatif sunarlar.

İkili

İkili programın avantajı hızlı ve kompakt olmasıdır. Dosyanızı okumak ve değiştirmek için gereken tek şey bir program olduğunda ve veriler ilişkisel paradigmaya veya hıza uymadığında gerçekten önemliyse, bu iyi bir seçim olabilir. Muhtemelen medya dosyaları için en uygun.

Yine de, ilk tasarım sırasında dikkate alınmayan nedenlerle bir noktada program verilerine basit erişimin gerekli olmadığı bir durumla karşılaşmadığımı belirtmeliyim. Günümüzde kişisel olarak standart formatları olan ve başka bir yazılım (örneğin ses, video) tarafından kodlanması / kodunun çözülmesi gereken dosyalardan başka bir şey için veritabanı seçeneğini tercih ediyorum.

Not: İkili sayının opak ve dolayısıyla bir şekilde daha güvenli olduğu konusunda yaygın bir yanlış anlama vardır. Ek koruma olmadan - birisi yazılımınızı hacklemek istiyorsa, konfigürasyonlarınızı veya ikili dosyadaki herhangi bir şeyi depolamak onları durdurmaz.

Sıkıştırılmış Arşiv

Yukarıdakilere gerçekten bir alternatif değil, ekstra bir önlem.

Bir şeyleri ağ üzerinden iletmeniz gerektiğinde veya çok fazla veri depoladığınızda ve yerden tasarruf etmek istediğinizde avantajlıdır. Depolama alanının bu günlerde genellikle bol olduğunu unutmayın, bu nedenle hedef platformunuzu düşünün.

Bugün hemen hemen her şeyde çok hızlı bir performans sergiliyor (Moore yasası, bebek), bu yüzden kullanmamanın tek nedeni kodunuza karmaşıklık katmasıdır. Çok fazla karmaşıklık değil, yine de KISS ilkesinin ihlali. Özellikle el ile veya komut dosyasıyla düzenlenmesi gereken yapılandırma dosyaları için hantal ve gerçekten de alandan tasarruf etmeniz gerekiyorsa, muhtemelen veritabanı seçeneğini kullanmalısınız.


2

Bunları şöyle kullanırdım:

  • Düz metin : Uygulamanın küçük boyutlu basit yapılandırılmış verileri vardır (örn. Ad değeri çiftleri). Veriler aynı anda birden fazla kullanıcı tarafından değiştirilmez.
  • XML : Eşzamanlı veya sık değiştirilmeyen yapılandırılmış verilerin küçük boyutu.
  • Veritabanı : büyük yapılandırılmış veri veya eşzamanlı erişim gereklidir. Uygulamada sorgulama ve arama ihtiyacı bir zorunluluktur.
  • İkili veri: Bunu sadece nesneleri akış için kullanırım.
  • zipping , sunuculardaki veritabanları dışında yukarıdakilerden herhangi biri için başka bir işlem olarak eklenebilecek sıkıştırmadır.

1

XML'in metnin en kötü özelliklerini (işlenmesi zor / yavaş) ve ikili (okunamaz) birleştirdiğini duydum.


Tam bir cevap değil
Anto
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.