我正在处理一个需要比较JSON对象内容的问题,我必须对许多记录重复这样做。我无法进行Apple与Apple的比较,因为我不得不跳过几个字段进行比较,而且Arrays中的数据可能具有不同的顺序。
对于Ex ,例如,以下JSON都被认为具有相同的内容
Json1:
{
"id":1,
"name":"John",
"dept":"HR",
"interests":["Reading","Cycling"]
}
Json2:
{
"id":5,
"name":"John",
"dept":"HR",
"interests":["Cycling","Reading"]
}
我们的计划是创建一个表并将比较逻辑移植到数据库查询中。稍后,这些数据将用于执行其他一些操作。
映射到数据库列(id,name,dept)的字段非常适合直接查询。 兴趣值可以增长并且是动态的,我想编写一个方法以使用“兴趣”数组中的值生成唯一的字符串,因此我没有将整个String存储到表中。
我将调用方法生成字符串,将其填充为兴趣列的值并插入表格中,同时在查询时,我将使用相同的< strong>方法来填充我的查询参数。
注意::我的JSON具有一些更复杂的对象,为简化起见,我采用了简单的JSON。
答案 0 :(得分:1)
您要以某种方式将长字符串存储在较短的空格中。该策略取决于您的需求。需要考虑的几件事:
SELECT
?)您有几种选择,各有利弊。
如前所述,执行此操作的正确方法是标准化引用。因此,一个(id, interest)
元组的表和另一个带有(data-id, interest-id)
引用的表将确保没有信息丢失。
例如18个字符:
The quick brown fox jumps over the lazy dog -> The quick brown fo
The quick brown fox jumps over the fence -> The quick brown fo
每当结果长度短于输入字符串时,截断都会导致信息丢失。这可能是问题,也可能不是问题。根据输入字符串的不同,可以从输入的任何一端(或实际上,在任何地方)截断。
例如md5:
The quick brown fox jumps over the lazy dog -> 9e107d9d372bb6826bd81d3542a419d6
The quick brown fox jumps over the fence -> 26d68913b492ebb7fe734b973a358ab8
同样,这会导致信息丢失:
但是,如果您可以忍受误报的风险,那么这可能是可行的。正如@HansKesting在评论中提到的那样,请确保在哈希(顺序,大小写)之前对数组值进行规范化。此策略的重要属性是哈希长度是固定的。
例如deflate:
The quick brown fox jumps over the lazy dog <-> eJwLyUhVKCzNTM5WSCrKL89TSMuvUMgqzS0oVsgvSy1SKAFK5yRWVSqk5KcDAFvcD9o=
The quick brown fox jumps over the fence <-> eJwLyUhVKCzNTM5WSCrKL89TSMuvUMgqzS0oVsgvSy1SKAFKp6XmJacCAC1yDsE=
压缩字符串可以使您有机会将字符串解压缩为原始格式。缺点是输出长度可变且未知–并且某些类型的输入比其他类型的输入更适合压缩。
结论,从您的问题和评论中读取,只有“适当的”关系方式看来是正确的,但散列可能是可行的。