為什么不能在前端連接數(shù)據(jù)庫呢？

zone 2022-06-28 14:14 回答0 收藏1

問題描述：本人是一個(gè)軟件工程大三的學(xué)生，最近突然在思考一個(gè)問題：為什么不能在前端連接數(shù)據(jù)庫呢？這個(gè)想法的起因是我最近在開發(fā)一個(gè)簡單的小項(xiàng)目，使用的是gin和vue的前后端分離結(jié)構(gòu)。然后我發(fā)現(xiàn)，后端部分所做的事情，說到底就是訪問和操作數(shù)據(jù)庫（可能因?yàn)槲易龅氖且粋€(gè)小項(xiàng)目），那這些事情能否交給前端來做呢？為此我思考了一下是否可行。首先，數(shù)據(jù)庫的數(shù)據(jù)需要處理?？赡躩s的執(zhí)行效率不及后端開發(fā)語言，但我覺得這應(yīng)該存在一個(gè)瓶頸。所以是否在以后會(huì)存在一個(gè)節(jié)點(diǎn)，讓js的數(shù)據(jù)處理能滿足大眾的需求。然后，就是數(shù)據(jù)庫連接和數(shù)據(jù)傳輸?shù)膯栴}?？赡苄枰_發(fā)一個(gè)新的協(xié)議來讓網(wǎng)頁和數(shù)據(jù)庫連接。但是有個(gè)新的問題，因?yàn)榫W(wǎng)頁是靜態(tài)資源，用戶可以隨意修改，那數(shù)據(jù)庫的安全也存在問題，我也不知道該怎么解決。最后，我的這個(gè)想法的實(shí)際意義可能不大，因?yàn)橄裎疫@樣的一個(gè)小項(xiàng)目畢竟是少數(shù)，而大多數(shù)項(xiàng)目肯定是原有的架構(gòu)能更好地實(shí)現(xiàn)功能。本人第一次提問，思路有點(diǎn)天馬行空，渴望理性探討，如果有邏輯硬傷，望大佬指出。

收藏問題

10條回答

MartinDai

回答于2022-06-28 14:14

假如淘寶這么做了，那就得打通客戶到數(shù)據(jù)庫服務(wù)器的網(wǎng)絡(luò)，同時(shí)在前端寫明數(shù)據(jù)庫賬號密碼實(shí)例名。我覺得挺好

評論0 贊同0

加載中...

荊兆峰

回答于2022-06-28 14:14

你的訴求是，如果后端只干了增刪改查，是不是可以干掉。

答案是當(dāng)然可以，而且這個(gè)思路符合邏輯。

但是干掉的方式有很多

1，瀏覽器直接和數(shù)據(jù)庫打交道。

這個(gè)思路早就有之，甚至在富瀏覽器之前。微軟在他的IE瀏覽器中提供了ActiveX的擴(kuò)展，允許你安裝插件。此時(shí)你如果安裝同樣是微軟的Access數(shù)據(jù)庫插件。就可以直接在瀏覽器操作數(shù)據(jù)庫了。

2，使用輕量數(shù)據(jù)庫嵌到前端。

富客戶端概念興起后，在前端存數(shù)據(jù)也不新鮮了。只是前端不認(rèn)為這是數(shù)據(jù)庫，更多認(rèn)為是緩存。因?yàn)樽罱K避免數(shù)據(jù)丟失，安全，一致性，還是需要后端的。此外，將sqlite類似的數(shù)據(jù)庫嵌到app是非常常見了，但是app可能不被認(rèn)為是“前端”。

3，打不過就加入，前端實(shí)現(xiàn)輕服務(wù)端。

正兒八經(jīng)說一下這一條。這個(gè)無疑是未來去除討厭的服務(wù)端的發(fā)展方向。借助nodejs，graphQL等框架，面向前端編程已經(jīng)非常流行了。這里也推薦題主看一下Prisma。堅(jiān)定自己想法，前端走遍天下是可行的。

評論0 贊同0

加載中...

BlackHole1

回答于2022-06-28 14:14

技術(shù)上可以，但是一般都不會(huì)這樣做，原因如下：

前端信息都是公開的，從前端訪問數(shù)據(jù)庫，就需要將數(shù)據(jù)庫的地址，密碼寫在前端的代碼中，這樣就相當(dāng)于公開了數(shù)據(jù)庫的訪問；
數(shù)據(jù)庫公開訪問的話，用戶就可以隨意訪問數(shù)據(jù)庫，操作數(shù)據(jù)庫，這是很嚴(yán)重的問題，比如隨便修改賬戶金額，刪除數(shù)據(jù)，盜取其他用戶敏感信息等；
無法擴(kuò)容，流量控制等，比如數(shù)據(jù)庫現(xiàn)在要遷移到另一臺(tái)設(shè)備上，可以地址已經(jīng)寫死到了客戶端，數(shù)據(jù)庫地址變了，前端就無法訪問了；
限制了數(shù)據(jù)庫表的修改，比如數(shù)據(jù)庫表中某個(gè)字段名變了，前端就訪問數(shù)據(jù)庫的代碼就掛掉了；
性能差，放在前端的話，限流，異步隊(duì)列，熔斷，兜底，緩存等服務(wù)端的一些高可用服務(wù)都沒有用武之地了。

因此，基本上數(shù)據(jù)庫訪問的業(yè)務(wù)代碼都是放在服務(wù)端的，客戶端通過訪問服務(wù)端來了解訪問數(shù)據(jù)庫。

評論0 贊同0

加載中...

894974231

回答于2022-06-28 14:14

你可以將現(xiàn)在的的“狀態(tài)”理解為就是前端直接鏈接了數(shù)據(jù)庫，并給他起個(gè)特殊的名字，比如“萌某數(shù)據(jù)連接”?！懊饶硵?shù)據(jù)連接”，“使用了多種協(xié)議”，為了“穿越多種”網(wǎng)關(guān)；使用了多種保護(hù)策略，用以保護(hù)鏈接的有效性；……。

評論0 贊同0

加載中...

Charlie_Jade

回答于2022-06-28 14:14

非專業(yè)人士，簡單回答一下:

前端連接數(shù)據(jù)庫，一個(gè)是安全問題，第二是并發(fā)性能問題，第三是系統(tǒng)的可維護(hù)性問題。

當(dāng)然第三個(gè)問題如果真想解決，通過一些設(shè)計(jì)還是可以解決的，第一第二問題那就關(guān)系到互聯(lián)網(wǎng)的一些基礎(chǔ)性東西，基礎(chǔ)決定上層建筑，目前的這些設(shè)計(jì)都是建立在這些基礎(chǔ)上形成的相對最優(yōu)的方案。

評論0 贊同0

加載中...

stormjun

回答于2022-06-28 14:14

也不是完全不行

我以前做程序的時(shí)候也是在前端直接連接數(shù)據(jù)，那時(shí)候我剛?cè)胄幸荒?，我們公司的?xiàng)目屬于內(nèi)網(wǎng)項(xiàng)目，不需要考慮什么安全問題，當(dāng)時(shí)我負(fù)責(zé)的一個(gè)模塊是基于applet的，使用java程序嵌入網(wǎng)頁。

我在applet里面寫了jdbc連接，然后使用js拼接sql，調(diào)用applet操作數(shù)據(jù)庫，完全不經(jīng)過后臺(tái)，開發(fā)起來非常方便，網(wǎng)頁刷新一下就能調(diào)試了，不需要重啟后臺(tái)。

不過那個(gè)項(xiàng)目也就客戶那邊幾個(gè)人在用，不存在安全性問題，也沒有并發(fā)問題，所以那樣做其實(shí)一點(diǎn)問題都沒有。

但是，如果是其他web項(xiàng)目甚至是互聯(lián)網(wǎng)項(xiàng)目，這樣弄純粹就是不想混了，在js里面寫sql，連接數(shù)據(jù)庫，別人稍微會(huì)點(diǎn)技術(shù)的，直接運(yùn)行一句delete，或者drop table，這時(shí)候你怎么辦，特別是你數(shù)據(jù)庫數(shù)據(jù)高達(dá)百萬或者十幾億的數(shù)據(jù)，足夠讓你公司破產(chǎn)了。

其實(shí)現(xiàn)在也是有一些基于web端的存儲(chǔ)，比如sqlite，websql，sessionstorage，localStorage，session，cookie，或者基于js自己實(shí)現(xiàn)個(gè)簡易數(shù)據(jù)庫，我曾經(jīng)就嘗試實(shí)現(xiàn)過js版數(shù)據(jù)庫，然后服務(wù)器上開著一個(gè)瀏覽器，后臺(tái)用websocket交互這個(gè)瀏覽器上的數(shù)據(jù)庫。

瀏覽器內(nèi)部提供的存儲(chǔ)一般是為了提升交互體驗(yàn)而使用，而不是直接存儲(chǔ)賬號密碼，特別是明文密碼或者其他重要數(shù)據(jù)，所以，不能為了完全的性能而忽略安全性問題。

但是如果是小型項(xiàng)目又是個(gè)內(nèi)網(wǎng)項(xiàng)目，本來就沒什么錢掙的項(xiàng)目，如果你覺得在前端存數(shù)據(jù)方便那就在前端存就行了，這種情況當(dāng)然是怎么開發(fā)快怎么來了。

評論0 贊同0