MS-SQL和NODE體系結構上的JSON響應的最佳實踐

Question

GoodDay，開始在Node上針對Azure上的MsSql進行試驗，以獲得非常以數據爲中心的解決方案。

對於這樣短的架構，最佳實踐是什麼？
（在數據庫中的所有通信進行槽存儲過程的，很明顯）

到目前爲止，我們與https://www.npmjs.com/package/mssql實驗，發現輸出參數持續一段時間，有時直到他們準備就緒...

因此，我們已經想到成：

• SP呼叫參數作爲獨立的輸入參數（更容易在SQL治療）
• 數據到節點應用程序作爲單個（有時構成）JSON，作爲recordse t
• SP執行代碼槽RETURN（202 ok，其餘代碼爲w3c網頁代碼）
• 返回消息，出錯時通過輸出參數。

任何跡象表明？

我發現很有趣的這個binomia（節點+ MSSQL），強度從一個側面，從另外一個靈活性和速度......

Answer 1

如果你打算回單JSON對象作爲記錄，是你計劃只用FOR JSON子句執行select查詢？ MSSQL supports JSON outputs，但即使沒有此功能，也許您可​​以使用pipe方法將結果流式傳輸到輸出流（我還沒有嘗試過）。 下面是一個示例應用程序，它使用單調乏味的流向JSON輸出到Http響應輸出： https://github.com/Microsoft/sql-server-samples/blob/master/samples/features/json/todo-app/nodejs-express4-rest-api/routes/todo.js並僅將FOR JSON生成的結果傳輸到Http輸出。它不使用MSSQL，但可以輕鬆將其重寫爲使用MSSQL。

如果您想將分塊數據返回給客戶端，那麼FOR JSON可能會很方便，因爲Azure SQL數據庫將大型JSON響應吐入2KB塊，但MSSQL使您可以將整個響應解析爲一個大對象。

關於錯誤處理，直接從存儲過程返回HTTP錯誤代碼作爲輸出參數可能有點不尋常。也許你可以使用標準的throw/raiserror語句並將錯誤代碼映射到Http錯誤代碼。在4xx和5xx範圍內有大約80個有用的Http錯誤代碼，所以即使錯誤狀態（tinyint）也足夠了。