創建文件格式時。創建多種格式還是有多個可選部分更好？

Question

假設我是一家軟件公司的技術負責人，專門爲廚師編寫應用程序，幫助組織食譜。最初我們正在爲麪包師製作一款應用程序，製作蛋糕，另一款面向壽司廚師。其中一個要求是創建用於導入和導出配方的標準文件格式。 （這種文件格式將成爲其他公司使用它來與我們的產品進行交互的行業標準），我們面臨兩種選擇：制定標準食譜格式（可以說.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文件類型？

Answer 1

這種事情會變得非常非常深刻的事情得到正確的。我想很多都取決於你想用食譜做什麼，而不僅僅是展示他們供廚師使用。

例如，是否希望在整個系統中規範化數據？也就是說，當一個食譜指定"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）。

或類似的東西。具有一些結構允許實現一些附加功能（例如，在屏幕上整理配方佈局）。對於整個事物來說，只有一個單一的自由文本字段意味着添加一個成分排序功能是很困難的 - 誰會說文本中的哪一行表示成分？

擁有單獨的文件格式將涉及到大量的模式。這將更加難以管理。