Neden CSV kullanmaya devam ediyoruz? [kapalı]

Neden CSV kullanmaya devam ediyoruz?

Kısa bir süre önce sağlık alanında çalışmaya geçtim ve veri aktarım standartlarındaki harika çalışmalara rağmen, tüm veri aktarımı CSV'de , hem dış kuruluşlara rapor vermek hem de yeni sistemler uygularken veri taşımak için.

Ne yazık ki CSV kullanımı, aynı aptal hataların, geliştirici süresinin aynı israfıyla sonsuz tekrarlanmasının nedenidir. (hatalı çıkış, boş alanları işlememe vb.)

Daha iyi yapabileceğimizi biliyorum ve JSON ve XML (örneğe bağlı olarak) arasındaki her şey iyi olurdu. (Çoğu zaman bu bir MS SQLserver 2005'ten diğerine giden verilerdir!)

Sanki bunu her gördüğümde tam anlamıyla bir geliştirici annesinin zamanını boşa harcadığımı hissediyorum.

Öyleyse neden birbirimizi şaşkına çeviriyoruz? Ne zaman duracağız?

Sizin durumunuzda, CSV'nin zor şartnameden yoksun olması nedeniyle iyi bir uyum olmadığı anlaşılıyor.

Önemsiz veriler için doğru seçim değildir.

CSV neden / ne zaman iyi bir seçim? Muhtemelen çok fazla örnek, düz veriler için sadeliğin faydaları açıktır. Veriler düzgün bir şekilde sterilize edildiği / kaçıldığı sürece herhangi bir sorun yoktur. Genel olarak konuşursak, tüm bu durumlar basit / önemsiz olacaktır. Elbette, içerikte görünen standart sınırlayıcı, CSV ile uğraşırken genellikle bir acıdır.

Ancak teknik olmayan bir istemciyi bir Excel sayfasından veya başka bir benzer kullanım durumundan veri göndermekten daha fazla bir şey yapıyorsanız, CSV muhtemelen herhangi bir ciddi kullanım için yetersizdir.

Bunun için ayrıntılı standart şema belirtimi yapabildiğiniz için XML çok daha iyi bir uyum (evet JSON'dan daha fazla). (Spesifikasyonların / şemaların birden fazla uygulama stilinin (XSD, DTD ve Relax NG) esnekliğinden bahsettiğinden bahsetmiyoruz bile)

Özellikle bant genişliğinin önemli olduğu kapalı döngü sistemlerinde JSON, XML'den daha uygun olabilir, ancak şema belirtim dillerinin eksikliği genellikle kurumsal düzey uygulamalardan kaçınır.

CSV lehine birkaç puan atayım:

• CSV'nin uygulanması ve ayrıştırılması basittir (OP'de önerilen herhangi bir alternatiften daha r)
• CSV, gezegendeki hemen hemen her yazılım parçası tarafından anlaşılmaktadır (geçmiş ve şimdiki)
• CSV oldukça düz, basit bir şemayı zorlar (tek bir düz alan listesi vardır)
• CSV, XML, JSON veya (UGH!) HL7'den (V2.x, pre-xml) daha fazla okunabilir

Geriye dönük uyumluluk. Dış kuruluş web hizmetiniz CSV'yi yönetiyorsa ve mevcut tüm araçlarınız CSV'yi işliyorsa, hiçbir tarafın yeni bir hizmete geçmek için herhangi bir motivasyonu yoktur. Harici kuruluşunuz neden farklı bir biçimi desteklemeye başlasın? Birlikte çalıştıkları hiç kimse kullanamaz! Neden farklı bir format üretmeye başlıyorsunuz? Çalıştığınız kuruluşların hiçbiri kabul etmiyor!

Gerçek Burada gördüğüm konu, bir neden geliştiricilerinin kendi CSV kodu her zaman kullanıma sunacağız? Eğer sağlam, kaya gibi sağlam bir CSV kütüphanesi kullansaydı, tarif ettiğiniz sorunlara sahip olmazlardı. Sorunlar geliştiricilerin bir kütüphane kullanmak yerine kendi çözümlerini yuvarlamalarından kaynaklanıyor ve dürüstçe JSON veya XML'e taşınmanın bunu sihirli bir şekilde nasıl düzelttiğini göremiyorum. Hala bir kütüphane kullanmak yerine onları yeniden düzenlemeye çalışan insanlar olurdu.

CSV biraz daha hızlı , daha küçük boyutlu , kullanımı çok kolay (Excel'de bile) ve mevcut birçok uygulama bunu anlıyor, yaygın olarak kullanılan bir standarttır .

Birçok durumda hala ilk tercihtir.

Ben şahsen hala bu formatı çok seviyorum. Ancak JSON'u da kullanıyorum, ancak web kullanıcı arayüzü gibi diğer uygulamalar için.

Birincisi ve en önemlisi, CSV verilerini tüketmek önemsiz olmasa da, bunu oluşturmak son derece kolaydır.

Ayrıca ne JSON ne de XML'in doğru bir şekilde elde edilmesinin daha kolay olmadığını da belirtmeliyim (üretici veya tüketici için). Aslında, bir çok insanın XML verilerini ayrıştırmak için normal ifadeleri kullanmaya çalıştığını bilmek neredeyse hiç etrafa bakmak zorunda değildir, ancak bunu yapmanın kesinlikle işe yaramayacağı ve çalışmayacağı konusunda hiçbir soru yoktur.

CSV ile ortaya çıkabilecek (ve yapabilen) sorunların çoğu hem JSON hem de XML ile ortaya çıkabilir. Özellikle XML, kendi başına çok daha fazla potansiyel sorun ekler. XML verilerini ayrıştırma kütüphanesi, CSV verileri için benzer bir kütüphaneden genellikle daha büyük, daha yavaş ve kullanımı daha zordur.

İlk olarak, formatta bazı çok gerçek problemler olduğunu kabul ediyorum:

• Bu sıkıca yazılmış.
  • Metin ve sayısal değerler arasında hiçbir ayrım yapılmazsa, Excel yanlış tahmin eder ve posta kodlarınızı ve kredi kartı numaralarınızı bozar.
  • İkili verileri temsil etmenin standart bir yolu yoktur.
  • CSV dosyalarını SQL veritabanlarına içe aktarırken sorun olan NULLve arasında ayrım yapmak için standart bir yol yoktur ''.
• "Özel karakterler" için zayıf destek.
  • (XML &#xNNNN;veya JSON \uNNNN) gibi sayısal karakter referanslarının olmaması, kontrol karakterlerini veya ASCII olmayan karakterleri temsil etmenin standart bir yolu olmadığı anlamına gelir.
  • Birçok uygulama, bir alandaki satır kesmelerini düzgün bir şekilde uygulamamaktadır.
• Bir standart eksikliği. Orada RFC 4180 ama evrensel olarak takip değil.

Ama diğer yandan:

• Alternatifler daha kötü. Ağaçların etrafında tasarlanan JSON ve XML, özellikle tablo bazında tablo tabanlı veriler için ...
• KOMPAKT! XML'de, her satırdaki her sütun için bir başlangıç ​​etiketi ve bitiş etiketi olması gerekir . CSV'de sütun başlıklarını yalnızca bir kez yazarsınız.
• CSV oluşturmak çok kolaydır.
• Programcı olmayanlar CSV dosyalarını Excel'de açabilir.

Birçok analist Excel kullandığından (pivot tablolar ve benzeri için) ve CSV çıktısı yerel Excel formatına göre çok daha kolaydır.

Dipnot: Excel'de CSV dosyalarını ele alırken, önde gelen sıfırları kaldırmak ve hassasiyeti kaybetmek gibi kaç sorun gördüğüm düşünüldüğünde, bu muhtemelen daha kolay olmanın yanlış bir hissidir.

CSV ile ilgili bir sorun varsa, CSV o kadar basit görünüyor ki birçok geliştirici kendi ayrıştırıcılarını / yazarlarını icat etmeye çalışıyor ve daha sonra kaçmayı doğru işlemediği için CSV'yi suçluyor. İyi bir CSV ayrıştırıcısıyla (çok iyi biri), hiç sorun olmayacak.

Bahsedilen bazı CSV önemsiz veriler için iyi değil, ancak kabul etmiyorum. Farklı veri kümeleri farklı "kapsayıcı" etiketlere yerleştirilebildiğinden XML önemsiz verilere izin verir. CSV ile aynı efekti elde etmek için her zaman farklı dosyalara farklı veriler koyabilirsiniz.

Ayrıca, bence, XML'i veri aktarımı için kullanmak temel olarak XML'nin amacına aykırıdır - veri aktarımı genellikle sağlayıcılar ve tüketiciler arasında istikrarlı bir sözleşme gerektirirken, XML tüketildiğinde yoruma tabi genişletilebilir bilgi taşımayı amaçlamaktadır.

Ben sadece CSV sadece basit metin verileri, sadece virgül ve sonunda noktalı virgül / bitiş çizgisi ile iyi olduğunu düşünüyorum.

Ağaç mimarisi verileri veya birleştirilmiş veriler CSV ile neredeyse hiç kullanılamaz.

CSV, excel'deki gibi düz bir 2D metin dizisidir, fazla bir şey değildir ...

Gerçekten ana bilgisayarlar ve burada excel ile ilgili.

Ana bilgisayarlar çünkü bu eski sistemler CSV kullanarak nasıl iletişim kuracağını anladı. Böylece, verileri döken büyük uygulamalar, bunları okuyabilir ve yazabilir ve şimdi değiştirmek için bir nedeni yoktur.

Excel CSV'leri doğrudan açabildiğinden. Aslında, yüklediğinizde .csv uzantısını alır. Kullanıcılar sadece biraz komik görünümlü excel simgesini tıklayın ve açılır ve kavga edebilecekleri güzel bir ızgara yapar.

Şimdi, excel'in modern sürümleri, örneğin XML'i doğrudan okuyabilir. Ancak bunu yapmak için, kullanıcının "bu resme çift tıklamaktan" biraz daha fazlasını anlaması gerekir. Ve doğru resme çift tıklamak bazı endüstrilerde sormak için çok fazla olabilir. . .

Çok fazla teknik cevap gördüm ama insanların CSV'yi kullanma nedenlerinin, insanların başka birçok teknik / teknoloji kullanmalarının aynı nedeni olduğundan şüpheliyim: çünkü en aşina oldukları şey bu

neden kullanıyorum?

1. müşteri bunu istiyor
2. ağ üzerinden xml'den daha hızlıdır (daha küçük ağ yükü)
3. Verileri elde etmek için daha karmaşık bir şeye gerek yok
4. çapraz platform
5. okunabilir insan
6. bunun için okuyucuları ve yazarları uygulamak kolay

vs vs.