Sql 表VS xml/json/yaml-如果数据相关，表需要更少的存储空间？比压缩效率更高

要将字段添加到XML对象，需要字段名的长度+ 3个字符（嵌套时为7个）和JSON 4个字符（嵌套时为6个）

• /和-值中的符号只需在头部转义

• 但是，，，，也可以是\4行中分隔符的转义数（当转义符号或字符串在大量空字段中声明为同样值时），并且由于转义字符和分隔符在值中出现时需要转义，因此它们可以自动声明为通常很少出现的罕见符号

验证/附加信息：XML/json将忽略所有空字段，因此无法注意到行中缺少的“字段”。只有字段数正确且必须注意（错误）行时，表中的一行才有效。但是，通过具有不同数据类型的列，缺少分隔符通常可以很容易地修复

编辑：

---

关于可读性/可编辑性：当然，好事情是，第一次阅读xml和json时，可能已经阅读了html和js，这是不言自明的，但仅此而已大多数情况下是机器读取，有时是开发人员读取，这两种情况可能都不喜欢冗长的内容。在您的示例中，CSV使用8位编码效率很低。你几乎不用5比特的熵，显然是浪费了3比特。为什么不压缩它呢

所有这些问题的答案都是人们会犯错误，而更强大的打字会以效率换取安全。机器或人工不可能在CSV流中识别转置的列，但是JSON和XML都会自动处理它，并且（假设没有跨越层次边界）一切都会正常工作。30年前，当存储空间不足时，每秒指令数有时为每秒100秒，在协议中使用最少的装饰是有意义的。如今，即使是嵌入式系统也拥有相对巨大的电力和存储容量，因此，为获得一点额外的安全性而进行权衡要容易得多

---

对于严格控制的数据传输，比如说我的开发团队正在处理的模块之间的数据传输，JSON非常有效。但是，当数据需要在不同的组之间传递时，我非常喜欢XML，因为它可以帮助双方理解正在发生的事情。如果数据需要通过一个“慢”管道，压缩将消除98%的XML“开销”。

XML的设计者很清楚表示中存在高度冗余，他们认为这是一件好事（我不是说他们是对的）。基本上，（a）如果使用数据压缩，冗余不会产生任何成本，（b）冗余（在一定范围内）有助于人类的可读性，（c）冗余可以更容易地检测和诊断错误，在手工编写XML时尤其重要。

感谢您的回答！我刚刚在粗体印刷的问题行@shawn cyes中添加了最后3句话和第二个问题，压缩允许用cpu换取带宽，我的带宽问题实际上只起到了很小的作用。谢谢你的回答！=）@michael kay（a）查询冗余嵌套数据需要更高的性能（？）（压缩也使用CPU）（b&c）就我个人而言，我阅读和理解表格的速度更快。最少的冗余似乎是最能激发阅读动机的。表格的二维（如适用）似乎更适合二维屏幕。b&c在哪里适用？（而不是通过[自定义]表单/可视化布局进行[大规模]编辑）反对表格的理由只是大多数数据不是表格。我们经常弯曲它使它看起来像表格，但现实生活中并非如此。书籍有不止一位作者，人们有不止一个电话号码，地址没有固定的行数，人们有不止一份工作。表格会说谎。你能澄清一下你使用JSON/XML/“表格”数据的情况吗？您是否在SQL数据库中存储数据？是的！不一定是SQL，只是xml和xquery对于相关数据来说效率不高

<xml>xml</xml>       xml="xml"    
{"json":json,}       "json": json,       

<aaaaahlongfieldname>1</aaaaahlongfieldname>
<b>B
  <c>C</c> 
</b>

<aaaaahlongfieldname>2</aaaaahlongfieldname>    
<b><c><d>D</d></c></b>
<ba>BA</ba>
<ba "xyz~">BA</ba>
<c>C</c> 

delimiter=,   
aaaaahlongfieldname,b,b/c,b/c/d,ba,ba-xyz~,c
,B,C,,,,
,,,D,BA,BA,C

escape=~   
delimiter=°  
aaaaahlongfieldname°b°b/c°b/c/d°ba°ba-xyz~~°c
°B°C~4
°°°D°BA°BA°C