Tại sao chúng ta tiếp tục sử dụng CSV? [đóng cửa]

Tại sao chúng ta tiếp tục sử dụng CSV?

Gần đây tôi đã chuyển sang làm việc trong lĩnh vực y tế và mặc dù công việc tuyệt vời trong các tiêu chuẩn truyền dữ liệu, tất cả truyền dữ liệu đều bằng CSV , để báo cáo cho các tổ chức bên ngoài và cho việc di chuyển dữ liệu khi triển khai các hệ thống mới.

Thật không may, việc sử dụng CSV là nguyên nhân của sự lặp lại vô tận của cùng một lỗi ngu ngốc, với cùng một sự lãng phí thời gian của nhà phát triển. (thoát tệ, không xử lý các trường null, v.v.)

Tôi biết chúng ta có thể làm tốt hơn và mọi thứ giữa JSON và XML (tùy theo thể hiện) sẽ ổn. (Hầu hết thời gian đây là dữ liệu đi từ một MS SQLserver 2005 đến một cái khác!)

Tôi cảm thấy như mỗi lần tôi thấy điều này xảy ra, tôi thực sự đang xem một nhà phát triển lãng phí thời gian của các bà mẹ.

Vậy tại sao chúng ta cứ trục nhau? Khi nào chúng ta sẽ dừng lại?

Trong trường hợp của bạn, có vẻ như CSV không phù hợp do thiếu thông số kỹ thuật cứng.

Đối với dữ liệu không tầm thường, nó không phải là lựa chọn đúng đắn.

Tại sao / Khi nào CSV là một lựa chọn tốt? Có lẽ quá nhiều trường hợp để đề cập, lợi ích của sự đơn giản cho dữ liệu phẳng là rõ ràng. Miễn là dữ liệu được vệ sinh / thoát đúng cách, không có vấn đề gì. Nói chung, mặc dù, tất cả những trường hợp này sẽ đơn giản / tầm thường. Tất nhiên, dấu phân cách chuẩn xuất hiện trong nội dung thường gây khó khăn khi xử lý CSV.

Nhưng nếu bạn đang làm gì đó liên quan nhiều hơn là bắt khách hàng không có kỹ thuật gửi dữ liệu từ trang tính Excel hoặc một số trường hợp sử dụng tương tự khác, thì CSV có thể không đủ cho bất kỳ việc sử dụng nghiêm trọng nào.

XML phù hợp hơn nhiều (có, thậm chí còn hơn cả JSON) vì bạn có thể thực hiện đặc tả lược đồ được tiêu chuẩn hóa chi tiết cho nó. (Không đề cập đến thông số kỹ thuật / lược đồ tận hưởng tính linh hoạt của nhiều kiểu triển khai, XSD, DTD & Thư giãn NG)

Đối với các hệ thống vòng kín, đặc biệt là vấn đề băng thông là mối quan tâm, JSON có thể phù hợp hơn XML, nhưng việc thiếu (các) ngôn ngữ đặc tả lược đồ thường loại trừ nó khỏi các ứng dụng cấp doanh nghiệp.

Hãy để tôi đưa ra một vài điểm có lợi cho CSV:

• CSV đơn giản (r hơn bất kỳ giải pháp thay thế nào được đề xuất trong OP) để thực hiện và phân tích
• CSV được hiểu bởi hầu hết mọi phần mềm trên hành tinh (quá khứ và hiện tại)
• CSV buộc một lược đồ đơn giản, khá phẳng (có một danh sách các trường phẳng)
• CSV dễ đọc hơn con người so với XML, JSON hoặc (UGH!) HL7 (V2.x, tiền xml)

Tương thích ngược. Nếu dịch vụ web orgs bên ngoài của bạn xử lý CSV và tất cả các công cụ hiện có của bạn xử lý CSV, không bên nào có động lực để chuyển sang dịch vụ mới. Tại sao org bên ngoài của bạn sẽ bắt đầu hỗ trợ một định dạng khác? Không ai làm việc với họ có thể sử dụng nó! Tại sao bạn sẽ bắt đầu sản xuất một định dạng khác nhau? Không có tổ chức nào bạn làm việc chấp nhận nó!

Các thực vấn đề tôi thấy ở đây là, tại sao các nhà phát triển của bạn lăn mã CSV của mình mỗi lần? Nếu họ sử dụng thư viện CSV ổn định, vững chắc, họ sẽ không gặp phải vấn đề bạn mô tả. Các vấn đề được gây ra bởi các nhà phát triển đưa ra giải pháp của riêng họ thay vì sử dụng thư viện và tôi thực sự không thấy cách chuyển sang JSON hoặc XML đã khắc phục điều đó một cách kỳ diệu. Bạn vẫn sẽ có người cố gắng đăng ký lại thay vì sử dụng thư viện.

CSV nhanh hơn một chút , kích thước nhỏ hơn , rất dễ xử lý (ngay cả trong Excel) và nhiều ứng dụng hiện có hiểu nó, đây là một tiêu chuẩn được sử dụng rộng rãi .

Nó vẫn là lựa chọn đầu tiên trong nhiều tình huống.

Cá nhân tôi vẫn thích định dạng đó rất nhiều. Nhưng tôi cũng sử dụng JSON, nhưng đối với các ứng dụng khác như giao diện người dùng web.

Đầu tiên và quan trọng nhất, vì mặc dù việc tiêu thụ dữ liệu CSV có thể (hơi) không tầm thường, nhưng việc tạo ra nó cực kỳ dễ dàng.

Tôi cũng chỉ ra rằng cả JSON và XML đều không thực sự dễ dàng hơn (đối với nhà sản xuất hoặc người tiêu dùng). Trên thực tế, người ta hầu như không phải nhìn xung quanh để biết rằng nhiều người cố gắng sử dụng biểu thức chính để phân tích dữ liệu XML, mặc dù hoàn toàn không có câu hỏi nào làm như vậy không thể và sẽ không hoạt động.

Hầu hết các vấn đề có thể (và làm) phát sinh với CSV có thể (và làm) cũng phát sinh với cả JSON và XML. XML, đặc biệt, thêm nhiều vấn đề tiềm năng của riêng nó. Một thư viện để phân tích dữ liệu XML thường lớn hơn, chậm hơn và khó sử dụng hơn so với một thư viện tương tự cho dữ liệu CSV.

Đầu tiên, tôi đồng ý rằng có một số vấn đề rất thực với định dạng:

• Nó được gõ một cách nghiêm ngặt.
  • Không có sự phân biệt giữa văn bản và giá trị số, Excel sẽ đoán sai và làm hỏng mã bưu chính và số thẻ tín dụng của bạn.
  • Không có cách chuẩn để biểu diễn dữ liệu nhị phân.
  • Không có cách tiêu chuẩn nào để phân biệt giữa NULLvà '', đó là một vấn đề khi nhập tệp CSV vào cơ sở dữ liệu SQL.
• Hỗ trợ kém cho "nhân vật đặc biệt".
  • Việc thiếu các tham chiếu ký tự số như (XML &#xNNNN;hoặc JSON \uNNNN) có nghĩa là không có cách tiêu chuẩn để biểu diễn các ký tự điều khiển hoặc các ký tự không phải ASCII.
  • Nhiều triển khai không thực hiện đúng các ngắt dòng trong một trường.
• Việc thiếu một tiêu chuẩn. Có RFC 4180 , nhưng nó không phổ biến theo.

Nhưng mặt khác:

• Các lựa chọn thay thế là tồi tệ hơn. JSON và XML, được thiết kế xung quanh cây, rất phù hợp với dữ liệu dựa trên bảng, đặc biệt là về ...
• TƯƠNG THÍCH! Trong XML, bạn phải có thẻ bắt đầu và thẻ kết thúc cho mỗi cột trong mỗi hàng. Trong CSV, bạn chỉ viết tiêu đề cột một lần.
• CSV rất dễ tạo ra.
• Những người không lập trình có thể mở tệp CSV trong Excel.

Bởi vì rất nhiều nhà phân tích sử dụng Excel (cho các bảng xoay vòng, v.v.) và việc xuất CSV dễ dàng hơn nhiều so với xuất định dạng Excel gốc.

Lưu ý: đưa ra có bao nhiêu vấn đề tôi đã gặp với Excel khi xử lý các tệp CSV, như xóa các số 0 đứng đầu và mất độ chính xác, đây có thể là một cảm giác sai lầm về việc dễ dàng hơn.

Nếu có một điều sai với CSV, thì CSV xuất hiện đơn giản đến mức nhiều nhà phát triển cố gắng phát minh ra trình phân tích cú pháp / trình soạn thảo của riêng họ và sau đó đổ lỗi cho CSV vì đã không xử lý thoát chính xác. Với một trình phân tích cú pháp CSV tốt (nhiều cái tốt ngoài kia), sẽ không có vấn đề gì cả.

Một số đề cập CSV không tốt cho dữ liệu không tầm thường nhưng tôi không đồng ý. XML cho phép dữ liệu không tầm thường vì các tập dữ liệu khác nhau có thể được đặt trong các thẻ "container" khác nhau. Với CSV, bạn luôn có thể đặt các dữ liệu khác nhau vào các tệp khác nhau để đạt được cùng một hiệu ứng.

Hơn nữa, theo tôi, việc sử dụng XML để truyền dữ liệu về cơ bản đi ngược lại mục đích của XML - truyền dữ liệu thường bao hàm một hợp đồng ổn định giữa các nhà cung cấp và người tiêu dùng trong khi XML có nghĩa là mang thông tin có thể mở rộng để giải thích khi nó được sử dụng.

Tôi đoán CSV chỉ tốt khi bạn chỉ có dữ liệu văn bản đơn giản, chỉ có dấu phẩy và dấu chấm phẩy / endline ở cuối.

Dữ liệu kiến ​​trúc cây hoặc dữ liệu tổng hợp khó có thể được sử dụng với CSV.

CSV chỉ là một mảng văn bản 2D đơn giản như trong excel, không có gì nhiều ...

Nó thực sự là tất cả về máy tính lớn và excel ở đây.

Máy tính lớn vì những hệ thống cũ đó đã tìm ra cách giao tiếp bằng CSV. Vì vậy, các ứng dụng lớn đổ dữ liệu có thể đọc và ghi dữ liệu và không có lý do gì để thay đổi ngay bây giờ.

Excel vì nó có thể mở CSV trực tiếp. Trong thực tế, nó chiếm phần mở rộng .csv khi bạn cài đặt nó. Người dùng chỉ cần nhấp vào biểu tượng excel trông hơi buồn cười và nó sẽ mở ra và tạo ra một lưới đẹp mà họ có thể sử dụng.

Giờ đây, các phiên bản hiện đại của excel hoàn toàn có khả năng đọc, nói, XML, trực tiếp. Nhưng để làm như vậy, một người dùng phải hiểu thêm một chút rằng "nhấp đúp chuột vào bức tranh đó". Và nhấp đúp chuột vào hình ảnh bên phải có thể là quá nhiều để hỏi trong một số ngành công nghiệp. . .

Tôi đã thấy rất nhiều câu trả lời về kỹ thuật nhưng tôi nghi ngờ lý do mọi người sử dụng CSV là lý do tương tự mọi người sử dụng nhiều kỹ thuật / công nghệ khác: bởi vì đó là lý do họ quen thuộc nhất

tại sao tôi sử dụng nó?

1. khách hàng muốn nó
2. nó nhanh hơn xml qua mạng (tải mạng nhỏ hơn)
3. không có gì phức tạp hơn là cần thiết để có được dữ liệu
4. đa nền tảng
5. con người có thể đọc được
6. dễ dàng để thực hiện các độc giả và nhà văn cho nó

Vân vân.