创建文件格式时。创建多种格式还是有多个可选部分更好？

问题描述：

假设我是一家软件公司的技术负责人，专门为厨师编写应用程序，帮助组织食谱。最初我们正在为面包师制作一款应用程序，制作蛋糕，另一款面向寿司厨师。其中一个要求是创建用于导入和导出配方的标准文件格式。（这种文件格式将成为其他公司使用它来与我们的产品进行交互的行业标准），我们面临两种选择：制定标准食谱格式（可以说.recipe），在适用的情况下使用公共属性和可选属性或者为每个应用程序制作独立的格式（让我们说.sushi和.cake）。创建文件格式时。创建多种格式还是有多个可选部分更好？

想象的文件格式会是这个样子寿司：

{ 
    "name":"Big California", 
    "type":"sushi", 
    "spiciness": 0, 
    "ingredients": [ 
    { 
     "name":"rice" 
     "amount": 20.0, 
     "units": "ounces" 
    }, 
    { 
     ... 
    } 
    ], 
}

和想象中的文件格式将是这个样子的蛋糕：

{ 
    "name":"Wedding Cake", 
    "type":"cake", 
    "layers": 3, 
    "ingredients": [ 
    { 
     "name":"flour" 
     "amount": 40.0, 
     "units": "ounces" 
    }, 
    { 
     ... 
    } 
    ], 
}

通知的文件格式非常相似只有spiciness和layers属性不同。毫无疑问，随着应用程序的复杂性和复杂性的增长，并且会导致添加更多的专用属性。其他类型的厨师也将增加更多的应用程序。在这种情况下，

更聪明的做法是让每个应用程序读/写符合标准化接口的.recipe文件，或者更聪明地删除所有相互依赖并让每个应用程序读/写各自的.sushi和.cake文件类型？

答

这种事情会变得非常非常深刻的事情得到正确的。我想很多都取决于你想用食谱做什么，而不仅仅是展示他们供厨师使用。

例如，是否希望在整个系统中规范化数据？也就是说，当一个食谱指定"flour"时，你想对那个面粉说什么，以及你想如何标准化？想象一下，一位厨师正在准备整个菜单，并且想知道该菜单中所有食谱使用了多少"plain white high gluten zero additives flour"。他们可能想知道这个，所以他们知道要买多少。实际上你可以说很多关于面粉的事情，这意味着只要有"flour"作为配方中的数据项目可能不够用。

关于这些事情的“现代”方式是简单地使用纯文本字段，并依靠某种灵活的搜索来使"flour, white, plain, strong"和"high gluten white flour"等字段之间进行等价关联。这就是Google所做的......

“正确”的方法是制定一个严格的模式，允许完全指定"flour"。很难想出一个文件/数据库格式的模式，可以详尽无遗地描述"flour"的每一个可能的方面。如果你太过分了，那么你有两个不同的“面粉”记录之间的关联问题，出于所有合理的目的是相同的，但在一些小方面有所不同。假设你有一个粒子大小的域;搜索将必须足够聪明以实现在面粉中没有真正的差异，例如平均粒度为0.5微米。

我们已经讨论了"flour"定义的可能范围。我们也必须考虑配料的制备方法。这增加了一个全新的难度。然后，人们不得不咀嚼所有的可调节厨房用具。人们可以看到*文本的吸引力...

考虑到这一点，我的目标是有一个单一的文件格式（.recipe），但不要打破数据太多。我会忘记试图将每种原料分类到最后的细节水平。相反，对于每种成分，我都会有一个*文本描述，然后可能是一个结构良好的数量字段（例如数字和单位，1和cup），最后是一段描述成分准备的*文本（例如sieved）。然后我会有一些描述准备步骤的东西，参考成分;这将有一些*文本字段和结构化字段（"sieve the","into a bowl"）。该文件将包含这些列表。您也可能有所需用具的列表，以及一般说明字段。您需要为配方元数据添加结构化字段（例如“蛋糕”或“寿司”或serves 2）。

或类似的东西。具有一些结构允许实现一些附加功能（例如，在屏幕上整理配方布局）。对于整个事物来说，只有一个单一的*文本字段意味着添加一个成分排序功能是很困难的 - 谁会说文本中的哪一行表示成分？

拥有单独的文件格式将涉及到大量的模式。这将更加难以管理。

创建文件格式时。创建多种格式还是有多个可选部分更好？

相关推荐