是一個多值存儲過程參數只是不好的做法？

我有一個奇怪的厭惡是將多個ID參數傳遞給一個存儲過程。例如，這種感覺只是錯誤：是一個多值存儲過程參數只是不好的做法？

GetMyObject（ListofIDs，OtherParam1，OtherParam2，...）

我知道如何（如果我必須正確）做到這一點..但我不喜歡我應該這樣做。我覺得它打敗了「get item」存儲過程/子例程的目的。我覺得我應該建立自己的SP來支持適當的過濾器參數。如果我的呼叫者有一個ID列表，他們不應該多次打電話給SP嗎？

幫助？

2010-07-20 deLux_247

如果一個調用者經常需要一堆對象，並且有一堆ID，我不會強迫他們多次調用這個單個過程。不同意GetItem（...）返回多個項目，但GetItems（...）沒有問題。數據庫調用很昂貴。 – seanb 2010-07-20 03:41:40

「通過ID獲取項目」例程不應該返回多個對象，因爲這絕對沒有語言意義。

「通過ID獲取項目」例程？當然，如果你有一個體面的用例，它會經常使用。

但是大多數情況下，是的，而不是通過ID返回多個項目的例程，您需要一個基於應用程序適當的過濾參數返回項目的例程（例如「從1月8日起給我所有交易超過10美元「）。順便說一句，有時候一系列的ID（例如5到10之間的所有東西）都是完全有效的過濾器組合！

順便說一下，這不一定只是一個MySQL或SQL中的一般問題。幾乎任何類型的查詢任何語言的API的數據集都會呈現這些相同的設計問題，他們的答案通常會非常相似。

來源

2010-07-20 02:16:42

我想這是一個有趣的思考方式。爲什麼不能將一系列ID作爲一組過濾器？我一次又一次看到的問題是，爲了「性能」，應用程序會在一次調用中想要所有項目（用於ID列表）。因此，他們不會撥打16個電話，而是要用16個ID撥打一個電話。 – 2010-07-20 02:20:48

@ deLux_247：如果應用程序需要這樣的調用，就把它給他們吧。對於某些用例來說這不是一個不合理的選擇。但是我會仔細研究_why_應用程序是否需要它 - 從哪裏獲取ID？如果他們首先來自數據庫，那爲什麼不直接請求所需的數據呢？真的會有那麼多ID嗎？例如，如果用例一次只有兩個或三個，我不明白爲什麼它不能爲每個ID調用一次，除非您的基礎架構嚴重超載。 – 2010-07-20 02:23:29

是一個多值存儲過程參數只是不好的做法？

回答

相關問題