CSV, XML ve JSON'a iyi bir alternatif midir? [kapalı]

CSV , programlama dilleri için XML ve JSON'a karşı iyi bir seçenek olarak mı kabul edilir ?

Genelde XML ve JSON'u (veya bazen düz bir metin dosyasını) düz dosya deposu olarak kullanıyorum. Ancak son zamanlarda PHP'de bir CSV uygulaması ile karşılaştım . Genellikle Excel dosyalarındaki girdiler için kullanılan CSV'yi gördüm , ancak programlamada hiç kullanmadım. Herhangi bir şekilde XML veya JSON'dan daha iyi olur mu?

Cevap, duruma bağlı.

CSV bazı kullanım durumları için mükemmeldir. Örneğin, büyük veri kümeleri için "akış" biçimi olarak, XML / JSON'dan akış yapmak kolaydır ve CSV dosyaları çok daha az depolama alanı kullanır. Bunu, diğer formatların pratik olmadığı gigabayt aralığındaki veri kümelerini yayınlamak için kullanıyorum.

Eski sistemler ve iş akışlarıyla uğraşırken bazı endüstrilerde de çok yaygındır. JSON'u MS Excel'e aktarmayı deneyin.

ODI kısa süre önce CSV hakkında yorum yaparak 2014 yılına "CSV Yılı" adını verdi .

"Doğru" CSV biçimlendirmesi için, HTTP yanıtlarınızda CSV mime türünü kullanmayı düşünün .

Kesinlikle hayır.

CSV, veri kümeleri veya diğer tablo verilerine çok iyi eşlenen bir tablo biçimidir. Ancak tüm veriler tablo halinde değildir! Genellikle, nesne grafiklerini serileştirmek istiyoruz . Bu, aşağıdaki durumlarda zor olabilir:

• dairesel referanslar
• paylaşılan alt yazılar (örneğin, her ikisi de üye ile aynı nesneyi içeren iki nesne)
• aynı belgeye serileştirilecek farklı türdeki nesneler

Ayrıca, nesneleri depolama biçimimizden güvenilir bir şekilde serileştirmek de istiyoruz.

XML

Öncelikle genişletilebilir bir biçimlendirme dilidir. Genel veri yapılarını da depolamak için ayakkabı boynuzlu olabilir. Kimlikler için dil desteği, en iyi ağaçlar için kullanılmasına rağmen karmaşık grafiklerin oluşturulabileceği anlamına gelir. Bir dokümantasyon şartnameye göre doğruluk için test edilebilir. Bu formatta, aşırı ayrıntı gibi pratik yapamayacağınız çeşitli problemler var.

JSON

Öncelikle basit nesne ağaçları saklamak için bir yoldur . Genel grafikler için destek yoktur. JSON, ilkel string , integer , float , boolean , null ve collection array dizisi ve nesnesinin ötesinde bir tür kavramına sahip değildir .

YAML

JSON'un bir uzantısı olarak en kolay anlaşılan Rasgele karmaşıklıktaki nesne grafiklerinin oluşturulmasına izin veren bir takma ad kavramı vardır . Doğru yazma için kullanılabilecek bir meta veri benzeri etiket kavramına sahiptir .

CSV

Tek bir masa dışında hiçbir şeye sahip değil. Nesne grafiklerini saklamak istiyorsak, şema gibi bir şema kullanmak zorunda kalırız.

#ID,Type,Field1,Field2,...,FieldN

1,String,foo
2,String,bar
3,Array<String>,1,2

Sınırlayıcılar, satır sonlandırıcılar, alıntılama, kaçış karakterleri ve genel (ikili) veriler için uygun olmayan diğer birçok konuya karşı çıkan pek çok CSV lehçesi vardır. Tüm bunlar CSV verilerinin işlenmesini oldukça zorlaştırır.

Dolayısıyla, temelde, CSV ile genel bir seri hale getirme biçimi olarak kullanıldığında kolay şeyler zor veya imkansızdır.

Bu eleştiri, zaman çizelgeleri veya bir dizi ölçüm gibi gerçekten tablo verilerini depolamak için kullanıldığında geçerli değildir. Burada, CSV (genellikle sekmeyle ayrılmış değerlerin bir varyantında), genellikle diğer veri formatlarından daha kompakt ve kullanımı kolaydır.

Ayrıca, elde etmeye çalıştığınız şeye bağlı olduğunu da söylemek isterim. Birçok sorun için, sorunun yeterince küçük olması ve tercihinizin mevcut sisteme uygun olması durumunda ne seçtiğinizin bir önemi yoktur.

Eski bir sisteme geçmek ve yeni bir formatta ayakkabı çekmeyi denemek bazen daha fazla karmaşıklık tanıttığınız ve hata ayıklamak için yeni bir giriş sistemine sahip olduğunuzdan bir problem olabilir. Bunu yeni insanlar var olandan farklı bir şey tercih ettiğinde veya yeni bir format göründüğünde ve denemek istediklerinde çok gördüm. Bu iyi bir fikir olabilir veya olmayabilir, şartlara bağlıdır.

Yıllar önce çeşitli formatlardaki CSV dosyalarına bağlı bir araştırma grafiği veritabanı sistemi üzerinde çalıştım. CSV dosya ithalatçısı bizim için grafikler hazırlar ve kodu ayıklamak ve optimize etmek için uzun yıllar süren bir çalışma yapmışlardır. Hem hızlı hem de esnekti ve büyük araştırma projelerini başlatmak için mutlulukla kullanırdık. XML sahneye çıktığında bir XML ithalatçısı ekledik, ancak hız veya karmaşıklığı ifade etmek açısından mutlaka bir gelişme olmadı ve kesinlikle XML, grafik yapılarını ifade etmede CSV'den daha iyi değildi. JSON, XML'den çok daha hoş (ve terser) ancak birçok bakımdan benzer, bu nedenle bu sistemde yeni bir ithalatçı oluştururken benzer bir sonuç beklerdim.

Bir noktada bir müşterimiz ("dediğimiz" biçiminde) büyük miktarda veri getirdi; bu satırda izlenen baytları nasıl yorumlayacağımızı belirten belirteç içeren değişken uzunluklu satırlara sahip dosyalar. Depolamanın pahalı olduğu bir zamandan beri, kompaktlık bir gereklilikti. Bu verileri anında CSV biçimine dönüştürerek ve CSV içe aktarıcısına besleyerek içe aktardık. Bunu yapmak kolaydı ve iyi şeyler olan hata ayıklama ve bakım miktarını en aza indirdi. Her zaman bu tür verileri almak zorunda kalırsak, performans ve verimlilik kazanımlarını elde etmek için doğrudan sisteme dahil etmiş olabiliriz.

Bu, ne yaptığınıza ve altta yatan sistemin ne yaptığına bağlıdır. Benim örneğimde CSV ithalatçısı sağlam bir şekilde tasarlandı ve güvenilirdi. Size, oluşturduğum diğer katmanlarda neler olup bittiğini anlamadan bir biçimin daha iyi veya daha kötü olduğunu söylemekte tereddüt ediyorum. JSON'u seviyorum ve tercih ediyorum, ancak belirli karmaşık veri yapıları ve yeterince büyük veri kümeleri verildiğinde CSV dosyalarının da çok iyi çalışabileceğini biliyorum.

Yok hayır.

CSV gerçekten tek bir format değildir. Kaçma, ayırıcılar ve vahşi ortamdaki birçok CSV dosyasının sahip olduğu diğer biçimlendirme sorunları için çok çeşitli stiller vardır.

Bunu düz bir dosya deposu olarak kullanacaksanız, JSON'u kullanmak size daha iyi hizmet verecektir. JSON, CSV'ye uymayacağınızdan çok daha az güçlük çeken nesnelere eşleme yapar ve nesnelerden eşler.

Buna karşı şiddetle tavsiye ediyorum. Bir noktada CSV çıkışı yapmak uygun olabilir (kullanıcı isterse). Ancak depolama / ithalat amaçları için uygun değildir. Bu çoğunlukla "CSV" nin çok kötü tanımlanmış olmasından kaynaklanmaktadır. "C", "virgül" veya "karakter" ayrıldığını gösterir mi? "Gibi kaçış karakterleri içeren metin dizelerini nasıl işlemden geçiriyorsunuz? Her lanetli CSV uygulaması kaçış karakterlerine vb. Farklı davranıyor;

Excel iyi bir gösteri: İngilizce sürümünde ayırıcı olarak "," kullanıyor. Almanya'da, ";" kullanır. Yani bir almanca sürümü ingilizce CSV dosyalarını boğuyor ve tam tersi ...

Asıl gücü, indirgenmemesi gereken insan okunabilirliğidir. Ancak depolama biçimi olarak kullanmayacağım, bu amaç için çok kırılgan. İnsanlar için dosyaları dışa aktarmanız gerekiyorsa, CSV'yi kullanabilirsiniz, ancak o zaman bile xlsx dosyalarına yazan bir kitaplığı kullanmaya çalışırım (serbestçe kullanılabilirler).

Genel olarak NO. Niye ya? JSON ve XML temelde korkunç CSV'den kurtulmak için oradalar. CSV ile uzun süredir yapılandırılmamış olanın yapılandırılmış yaklaşımlarıdır. Evet, CSV'nin hala tercih edildiği bazı kullanım durumları vardır, ancak genel olarak 10 vakanın 9'unda CSV kullanmamanız daha iyidir.