1樓：codefollower
前端直接訪問後端資料庫很容易實現的，只是這麼用的人不多，通常是不想把業務邏輯直接暴露在前端。
我做的資料庫 Lealone 幾年前就可以在前端直接訪問了。
比如在前端像後端一樣用 ORM 框架來訪問後端資料庫lealone/Lealone-Plugins在前端還可以控制後端事務的開始和結束
lealone/Lealone-Plugins用 async/await 來執行 SQLlealone/Lealone-Plugins甚至不用 async/await 也能用 Web Worker 來模擬同步執行 SQL
lealone/Lealone-Plugins總之，技術上沒有什麼難度，主要還是業務層面的問題。
如果業務沒有什麼可保密的，那後端只需要乙個資料庫配上乙個支援 http/websocket 協議的伺服器即可，所有業務功能都在前端實現。
2樓：我在對面的角落
其實很久以前是有從前端訪問資料庫的方式的，那時候前後端還沒有分離，大家都在asp，jsp，PHP頁面裡面寫sql，安全方面只要處理得當也不會有什麼大問題，但現如今只有PHP還活著了。
3樓：
很多人提到安全性，但是原理解釋得不太對。
首先很多資料庫是支援除了使用者名稱密碼以外的認證方式的，比如SSL證書，Kerberose, LDAP等。所以說前端直連資料庫會暴露使用者名稱密碼的問題，其實是有解決方法的。
其次，資料庫系統大多支援複雜的使用者管理和鑑權機制。只要管理得當，理論上可以做到乙個使用者只能訪問自己能訪問的資料。雖然實際上操作起來會很麻煩，相當於把鑑權的邏輯全都轉嫁給資料庫了。
一些特別小的CRUD專案，如果對安全性、可靠性沒有很高要求的話，的確可以讓前端直接訪問資料庫。另外，一些行業的桌面軟體就是這麼做的。只不過這些軟體的前端大多不是Web前端。
最典型的例子就是一些傳統的ERP系統，一般都是客戶端直連伺服器上的資料庫的。他們沒有現代意義上的後端。每個客戶端程式都包含了全套的業務邏輯，相當於前後端都在乙個程式裡。
大型的CRUD系統需要乙個後端的原因是，要處理複雜的業務邏輯，並且這些業務邏輯是跨使用者的。舉個簡單的例子，乙個電商系統需要處理訂單、庫存、物流等資訊。這些資訊只有一部分是和終端使用者互動的。
那些不直接和終端使用者互動的邏輯，總要寫在伺服器上。這種情況下，把所有業務邏輯都實現在後端，便於軟體工程管理。此外，再考慮到安全性、可靠性等，最後前端就「退化」成了乙個只用於呈現資料和使用者互動的介面。
4樓：florent
早在沒有前後端概念的時候，大概就是跟你說的比較類似。前端不能直接連線資料庫，最大的原因就是安全吧，直接連資料庫，使用者名稱密碼等於全網公開了，想不出什麼專案是可以這麼幹的。
你要是覺得前端頁面互動操作不是很複雜，主要是靜態展示，完全可以試試那些靜態頁面渲染模板，也挺好用的。
5樓：無以言
沒啥不對的，前後端所謂的分離，被各種糟七糟八的框架固化了唄。像你這種需求，無需多考慮前後端什麼的，類似服務端或blazor元件這種技術更合適。不過資料庫還是要適當隔離下的。
6樓：
其實有可以前端直連資料庫的，unicloud中的clientDB就是前端直連資料庫的，只是資料庫表需要做好schema對資料庫做一些規範
7樓：小鷺
前端不是不能連資料庫。是不能連別人的資料庫。這既不是技術問題，也不是安全問題。
你說的資料庫指的是伺服器的資料庫，服務端自己連自己的資料庫就像用自己的鑰匙開自己家門一樣自然。哪怕你安全控制的再好，你敢把鑰匙發給陌生人，隨便到你家參觀嗎？
一般的客戶端，特別是web方面的沒有那麼多本地儲存的需求，所以都是請求伺服器拿資料。但是有儲存需求的客戶端也會有本地資料，快取。用檔案，sqlite等方式來儲存到本地。
web方面的cookie，local storage等也可以理解為資料庫。
8樓：
你是想在前端連資料庫還是想在前端寫SQL？
這是兩個問題。
前者不可行，原因其他答案已經說的很清楚了，安全性什麼的。後者可行，只要把SQL編譯成介面呼叫即可，參見GraphQL，當然還是有很多限制，不如SQL功能多，後端接入成本也比較高。
9樓：黃亮anthony
顯然是能的，也並沒有太多問題。
首先，2023年了，前端不見得只是web執行在瀏覽器，還可以在各種前端容器中，比如electron,手機的web view，這些前端鏈結本地的資料庫有什麼不可以？這其實上退回了早期的GUI直連資料庫的單一應用，只是GUI是用現在的web技術實現。
其次，web系統也可以直接連線資料庫，但這個不是mysql，sql server這些傳統意義上的資料庫，而是經過改造的專用資料庫，比如google的firebase.
是否選擇這種模式，主要不在於題目中談到的那些問題。這個問題和為什麼有二層，以及三層，甚至多層架構一樣，要解決如何橫向擴充套件，如何用更多的機器支援管理更多的資料或更多的使用者？
安全是乙個成本問題，只會選擇可接受的範圍，但不是乙個可行性的問題。
另外，問題中提到的幾點，簡要回答如下：
js的執行效率不如後端語言，但是否夠用還是看應用。一般資料量的增刪改查應用，我想沒有問題。
安全連線的問題，基於https和token雙向認證模式，最少能達到當前web應用的安全需求。
還有一種思路是BaaS，後端即服務，當這裡的服務就是乙個資料庫時，也等同於前端直接連線資料庫。
10樓：光焰萬丈
不安全，有想法是好的。
首先要知道前後端分離的bs架構中。任何使用者輸入的安全驗證，不管前端做沒做驗證，後端都要驗證。前端驗證的目的是提高使用者體驗，後端驗證的目的才是加強安全性。
可以說前端就是本後端的使用手冊，使用者按照你的手冊來操作你可以提供更好的體驗，使用者不按你的手冊操作的話你是管不了的。畢竟服務端和前端是兩個單獨的系統，彼此之間必然有溝通手段，那麼就得考慮使用者不用前端直接使用該溝通手段和後端通訊的情況。也就是作為後端必須要考慮無前端的情況下自己的服務是個什麼服務，在對外暴露什麼。
如果前端直連資料庫那麼就需要對外暴露乙個可以直連的資料庫，你要想現在一些不好反編譯的單機遊戲都恨不得把存檔資料扔在服務端了，那畢竟只有服務端靠譜。雖然說可以設計成只能兩三個人可以訪問的內網環境，但畢竟多數情況軟體是要給多數人訪問的。只有少數人能訪問的話，那要為什麼要立項開發呢？
程式設計師自己手敲命令列呀。
引申一下可以思考一下，驗證碼這件事是否可以僅僅由前端搞定呢？前端驗證後把驗證結果告訴服務端。
11樓：劉幹臣
前端可以連資料庫，而且現在還有現成的解決方案，比如firebase。
自己做也簡單，不過需要搞乙個簡單的伺服器中間層，用於token，加密（這個可要可不要）。
12樓：yipzale
看你說的前端指什麼了。資料庫如果mysql的話，服務啟動之後就是監聽socket處理來自客戶端的指令。如果前端指瀏覽器的話，它只傳送http請求，所以沒辦法在瀏覽器上直接連線mysql。
我們為什麼要使用資料庫連線池？
Drol 應用程式和資料庫建立連線的過程是這樣的 首先通過TCP協議的三次握手和資料庫伺服器建立連線，然後傳送資料庫使用者賬號密碼，等待資料庫驗證使用者身份。2.完成使用者身份驗證後，系統才可以提交SQL語句到資料庫執行。3.好了這個時候假設我們不使用資料庫連線池，那麼完成一次SQL查詢後，我們還要...
前端平時有什麼資料庫，只會mongoDB可以嗎？
可以是可以，不過還是看一下關係型資料庫如pg文件型mongo 記憶體kv型redis，高效能kv型leveldb.等等，橫向對比學習一下更好 Mongo讀寫效能實在太弱了 疏義 Firebase 不知道國內有什麼替代，不過只有firebase這類是前端可以直接用的db，不然直接用redis,mysq...
為什麼說HBase是列式資料庫？
向上的蝸牛 不是列資料庫。準確說Hbase 是面向列族 kv 儲存。在實際場景中，列族幾乎都是當作表來使用。和greenplum 那些列式儲存差別很大。 陳葉超 HBase 準確說應該是kv資料庫，每個列與rowkey，時間戳等組成乙個kv，列式資料庫的說法可能原因是HBase是把不同列族的資料放在...