JSON哲学[关闭]答案

【问题标题】：JSON Philosophy [closed]JSON哲学[关闭]
【发布时间】：2012-08-25 18:47:12
【问题描述】：

我爱上了 JSON 并且痴迷于 JSON。我正在使用 node.js 和 mongodb，我在两种不同的哲学之间左右为难。

{
    "app":{
        "keys":{
            "facebook":{
                "apikey":"1412v5l1v5jv5j1h2v5",
                "sharedsecret":"v5j12hv51hc4v123vmnv",
            },
            "twitter":{
                "apikey":"3241bly5vlv1l2hjv51",
                "sharedsecret":"gxdz1n25f1m235xm1235",
            }
        }
    }
}

{
    "app":{
        "keys":{
            "facebook_apikey":"1412v5l1v5jv5j1h2v5",
            "facebook_sharedsecret":"v5j12hv51hc4v123vmnv",
            "twitter_apikey":"3241bly5vlv1l2hjv51",
            "twitter_sharedsecret":"gxdz1n25f1m235xm1235",
        }
    }
}

3 甚至

{
    "app":{
        "facebook_apikey":"1412v5l1v5jv5j1h2v5",
        "facebook_sharedsecret":"v5j12hv51hc4v123vmnv",
        "twitter_apikey":"3241bly5vlv1l2hjv51",
        "twitter_sharedsecret":"gxdz1n25f1m235xm1235",
    }
}

让数据更加复杂

{
    "app":{
        "keys":{
            "facebook":{
                "production":{
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",                  
                },
                "development":{
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",                  
                },
            },
            "twitter":{
                "production":{
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",                  
                },
                "development":{
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",                  
                },
            }
        }
    }
}

或者

{
    "app":{
        "keys":{
            "production":{
                "facebook":{
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",
                },
                "twitter":{
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",
                },
            },
            "development":{
                "facebook":{
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",
                },
                "twitter":{
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",
                },
            },
        }
    }
}

你应该去多深？有什么东西太远或太远了？

【问题讨论】：

我猜是品味和实用性的问题？
投票给#1。更清晰、更细粒度的数据。
这些让我想到了关系规范化。我不会结合。我也同意过深是没有意义的。但这一切都取决于上下文。太深或太宽会让我开始思考它是否仍然有意义。

标签： json mongodb

【解决方案1】：

我会使用以下内容，实际上确实使用了与以下内容非常相似的内容：

{
    "app":{
        "production":{
            "facebook":{
                "apikey":"1412v5l1v5jv5j1h2v5",
                "sharedsecret":"v5j12hv51hc4v123vmnv",
            },
            "twitter":{
                "apikey":"1412v5l1v5jv5j1h2v5",
                "sharedsecret":"v5j12hv51hc4v123vmnv",
            },
        },
        "development":{
            "facebook":{
                "apikey":"1412v5l1v5jv5j1h2v5",
                "sharedsecret":"v5j12hv51hc4v123vmnv",
            },
            "twitter":{
                "apikey":"1412v5l1v5jv5j1h2v5",
                "sharedsecret":"v5j12hv51hc4v123vmnv",
            },
        }
    }
}

当我设计一个系统时，我希望创建处理多种不同情况的通用代码。这通常意味着在设计中创建一致性。

上面允许您创建一个查找“应用程序”的例程，然后选择一个操作环境，“生产”或“开发”。然后可以将其交给另一个功能并要求找到您关心的特定服务，无论是“facebook”、“twitter”，还是像“foursquare”这样的新服务。然后，无论传入的对象如何，单个 oAuth 函数集都可以处理授权过程，因为它始终能够请求“apikey”和“sharesecret”，而不管正在使用哪个服务。

谈到 Mongo 甚至 Javascript 的灵活性……我喜欢这种灵活性。它使我们能够有效地解决在其他工具集中更困难的问题。但是，如果您要获得代码效率和易于调试，则需要尽可能保持一致性来调整这种灵活性。

【讨论】：

在您发布此内容之前，我使用了这个示例，这证实了我的推理。感谢您的帖子。

【解决方案2】：

嗯，这取决于。

从语义上看，如果您希望将更多应用添加到该列表中，#1 更正确。如果应用程序列表是固定的（即总是有两个），那么可以考虑#2 。但一般来说，你总是使用 #1，因为它更干净。

以上对于 XML 来说是正确的。由于 JSON 主要是关于 序列化，因此您选择一个对您来说最容易使用的。您将处理数据，并且您最清楚是否有深度嵌套结构的问题。

【讨论】：

【解决方案3】：

在我看来，你正面临着与所有尝试设计类设计/XML 设计/SQL 模式设计的开发人员类似的困境：)

根据我的经验，你基本上应该分组：

什么对你有意义
什么是合乎逻辑的
并且易于扩展和维护。

你还应该记住的是：

您如何访问/处理数据及其背后的行为。

我喜欢把事情安排得尽可能合理，所以我很可能会采用第一种方法。然而我的经验是，我使用数据的次数越多，我就越能看到优化其结构的方法。所以我会尽量让它为以后的重构做好准备。 :)

【讨论】：

【解决方案4】：

这可能看起来很奇怪，但重点是 MongoDB，它允许您这样做：

{
    "app":{
            "facebook":{
                "keys" : {
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",
                }
            },
            "twitter":{
                "keys" : {
                    "apikey":"3241bly5vlv1l2hjv51",
                    "sharedsecret":"gxdz1n25f1m235xm1235",
                }
            }
        }
    }
}

为什么？

嗯，答案就是 NoSQL 数据库出现的原因：您不确定数据结构。考虑添加，例如routes 字段转"facebook"：

            "facebook":{
                "keys" : {
                    "apikey":"1412v5l1v5jv5j1h2v5",
                    "sharedsecret":"v5j12hv51hc4v123vmnv",
                },
                "routes" : {
                     "mainroute" : "00.00.server.xx1",
                     "subroute" : "00.01.server.yy2",
                }
            },

而且该信息与twitter 无关，因为推特不支持假设的routes 功能。

如果您拥有#1 中建议的集合，会发生什么？

{
    "app":{
        "keys":{
            "facebook":{
                "apikey":"1412v5l1v5jv5j1h2v5",
                "sharedsecret":"v5j12hv51hc4v123vmnv",
            },
            "twitter":{
                "apikey":"3241bly5vlv1l2hjv51",
                "sharedsecret":"gxdz1n25f1m235xm1235",
            }
        },

        "routes" : {
            "facebook" :    {
                "mainroute" : "00.00.server.xx1",
                "subroute" : "00.01.server.yy2",
             }
        }
    }
}

看起来有点多余，不是吗？

【讨论】：

所以这允许api.keys.facebook.apikey 和api.facebook.apikey 相同？
是的，但我猜你不会复制太多信息。正如其他人所说，这完全取决于您为其设计数据结构的情况。例如，如果逻辑需要访问每个应用程序的数据，那么将应用程序信息存储在一个文档（对象、字典）中是明智的。另一方面，如果它是您需要访问的 production / development 键 - #1 非常有意义。