數據庫責任

Question

我以Databases開頭。我一直在玩MySQL和Informix，但從未有過真正的生活項目。

數據庫的真正責任是什麼？我們是否應該將存儲過程和函數添加到數據庫中，還是讓它成爲沒有邏輯的數據存儲庫？

Answer 1

通常認爲不要將業務邏輯放在數據庫中是很好的做法。主要原因是可維護性。仍然可以使用存儲過程，但在這些存儲過程中包含業務邏輯會使應用程序更難調試和更新。

在您的數據庫中包含業務邏輯也將有效地使您使用那個DBMS，並且不允許數據層獨立於您的應用程序。例如，一旦您的應用程序處於運行狀態，您可能會遇到一個數據庫的性能和可伸縮性問題，但由於散佈在整個數據庫中的業務邏輯，遷移到更具可伸縮性的數據庫最多隻會耗費大量時間。

如果業務邏輯保存在應用程序代碼（例如java或c＃）中，並且數據層使用數據抽象層抽象，並且ORM（如果語言允許），則交換數據庫的問題要少得多。

我們應該努力尋求separation of concerns，並且保持db的業務邏輯有助於實現這一點。

編輯：還有一些性能方面的問題可能決定存儲過程是保持業務邏輯的好地方。在某些情況下，在數據層（即存儲區）中包含邏輯可以減少數據抽象層和數據庫之間的多次往返，這可以提高性能。過去我一直在使用這樣的系統，因爲這個原因，但是我一直覺得很難維護。問題是你可以通過類和過程來查看業務邏輯，並認爲這是它，你不會看到如何發生一個特定的錯誤或過程，然後你會發現存儲過程，並看到另一半（當存儲介質是1000行時真正的痛苦！）

與許多事情一樣，放置業務邏輯的位置取決於您嘗試解決的特定問題。

Answer 2

我們周圍有很多數據可以用於我們。有序的信息收集有助於企業做出更適當的決定。數據庫是有序存儲的信息。

責任：在一個通常情況下，我們可以說周圍有很多信息，有序的信息收集稱爲數據，這個信息涉及到一個實體，而有序的數據收集是一個數據庫，有關的信息一組實體。這些數據庫的集合是一個DBMS。數據庫的責任是組織信息。

存儲過程，功能更像您需要的業務流程，以便收集您想要的數據。

第一齣發點，

開始： 在{PostgreSQL的，MySQL和SQL服務器（Express版本）}選擇數據庫和安裝。 瞭解有關Codd Rules，Normal forms，Good resource 開始學習SQL，編寫查詢。 瞭解涉及模式創建的基礎知識。 學習數據庫中的過程語言實現。 在SO中提出疑問。

Answer 3

數據庫的真正責任是什麼？

在其核心數據庫是存儲和檢索數據的系統。磁盤上的CSV文件+合適的工具（例如Excel）就是一個簡單的例子。另外，數據庫可能會提供額外的功能，例如事務控制，數據完整性和安全性。

我們應該增加存儲過程和函數以取消數據庫，還是讓它成爲無邏輯的數據倉庫？

你想從數據庫中得到什麼？如果你想要的只是一個「位桶」，那麼無論如何，將它存儲在磁盤上的普通文件中並稱之爲「數據庫」。如果您想要多一點，請使用適合您需求的產品。如果你想能夠使用4GL像SQL查詢它，請使用MySQL。如果您想要事務控制，安全性，高級查詢功能等，請在適當的情況下使用其他DBMS。無論您選擇哪種產品，都可以利用該產品的優勢。否則，你會浪費你的時間和金錢。當然，你永遠不會使用所有的功能（只有一個子集對你有用），但如果你使用的功能很少，你可能會降級到一個更簡單的產品。

如果您正在使用Oracle，您可以在數據庫中存儲旁邊的數據程序和功能（甚至更好，全包）就在那裏。真正的問題是，你需要在這些過程和函數中寫什麼 - 業務邏輯或表示邏輯？個人而言，我通常更傾向於保持業務邏輯接近數據，而表示邏輯是爲每個接口定製的。

它可以創建您的數據的API層，這樣無論你的應用程序如何訪問數據庫，他們將得到的是一致的視圖，並使用一致的機制，他們將所有的修改。換句話說，不是多次編寫業務邏輯（每個接口一次），而是隻編寫一次，然後在任何地方重新使用它。

有兩個原因，我聽說過，爲什麼業務邏輯不應該存儲在數據庫中：

1可維護性：這是很難改變的。我從來沒有真正理解這一個。輸入CREATE OR REPLACE PACKAGE有多難？我懷疑這只是不得不學習「另一種語言」的負擔。

2.數據庫獨立性：什麼作品在Oracle將不會在其他地方工作。這是一個biggie，和better minds than I有written about這一個。基本上，如果你真的需要它是「數據庫不可知的」，你將無法使用你購買的數據庫的任何高級功能，所以你可以使用最簡單/最便宜的一個，你可以找到;在這種情況下，無論如何您都不需要它來處理每個數據庫！