为什么不能在前端连接数据库呢

假如淘宝这么做了，那就得打通客户到数据库服务器的网络，同时在前端写明数据库账号密码实例名。
我觉得挺好
参考：
你可以将现在的的“状态”理解为就是前端直接链接了数据库，并给他起个特殊的名字，比如“萌某数据连接”。
“萌某数据连接”，“使用了多种协议”，为了“穿越多种”网关；
使用了多种保护策略，用以保护链接的有效性；
……。

参考：
非专业人士，简单回答一下:前端连接数据库，一个是安全问题，第二是并发性能问题，第三是系统的可维护性问题。
当然第三个问题如果真想解决，通过一些设计还是可以解决的，第一第二问题那就关系到互联网的一些基础性东西，基础决定上层建筑，目前的这些设计都是建立在这些基础上形成的相对最优的方案。

参考：
你再仔细想想，如果前端能直接访问数据库，前端必然有数据库连接信息，那么用户就可以通过其他手段访问你的数据库，你还有什么秘密可言？

参考：
因为要分工，你不能把一个人把所有事情都干了。
每个人做好自己的事，可以提高效率。
模块化方便，查找问题比较快速。
便于更多人协同作业。
就象前端还有三种文件一样，不然，你全弄些二进制数据，一个文件搞定。

参考：
也不是完全不行我以前做程序的时候也是在前端直接连接数据，那时候我刚入行一年，我们公司的项目属于内网项目，不需要考虑什么安全问题，当时我负责的一个模块是基于applet的，使用java程序嵌入网页。
我在applet里面写了jdbc连接，然后使用js拼接sql，调用applet操作数据库，完全不经过后台，开发起来非常方便，网页刷新一下就能调试了，不需要重启后台。
不过那个项目也就客户那边几个人在用，不存在安全性问题，也没有并发问题，所以那样做其实一点问题都没有。
但是，如果是其他web项目甚至是互联网项目，这样弄纯粹就是不想混了，在js里面写sql，连接数据库，别人稍微会点技术的，直接运行一句delete，或者drop table，这时候你怎么办，特别是你数据库数据高达百万或者十几亿的数据，足够让你公司破产了。
其实现在也是有一些基于web端的存储，比如sqlite，websql，sessionstorage，localStorage，session，cookie，或者基于js自己实现个简易数据库，我曾经就尝试实现过js版数据库，然后服务器上开着一个浏览器，后台用websocket交互这个浏览器上的数据库。
浏览器内部提供的存储一般是为了提升交互体验而使用，而不是直接存储账号密码，特别是明文密码或者其他重要数据，所以，不能为了完全的性能而忽略安全性问题。
但是如果是小型项目又是个内网项目，本来就没什么钱挣的项目，如果你觉得在前端存数据方便那就在前端存就行了，这种情况当然是怎么开发快怎么来了。

参考：
能不能只是一个技术问题，是否适用应该是考虑的重点。
前端可以连接数据（不考虑任何因素的情况）目前为止，很少有人这么做。

参考：
前端自然也能连接数据库啊[送心] 只不过按现在的套路，不建议而已，好比你回家，走大门进还要掏钥匙，多麻烦，爬窗户不行吗，还不用掏钥匙，多好，这当然也是可以的[可怜]
参考：
你想想，前端目前所有能够建立的链接都是基于http(s)的，也就是tcp的上一层。
而数据库的链接接口大部分是基于tcp的，当然现在新型数据也有直接提供http接口的。
那前端链接数据库就有两种选择，一是选择有http接口的数据库，比如influx等；
而是做一个代理接口http请求转tcp。
比较现实的还是后一种，那这个http接口怎么设计呢？
http直接传SQL？
其实也行，但是对前端太不友好了，前端同学肯定是喜欢rest json这一套的，所以现在其实已经有很多这种基于rest+json访问数据库的项目了，比如strapi等，这种项目叫做headless api。
然后，前端小朋友发现这种简单实现增删改查的api还是不能满足大部分需求，还是没有直接SQL灵活。
所以Facebook又为前端打造了graphQl，有了这个那可就爽了，用个前端接口几乎可以实现跟SQL一样的效果，而且是json格式的。

参考：
因为前端没有秘密可言
参考：
oracl e数据库专门有一个utl_http api，让数据库有类似java. servlet的功能；
可以了解一下和楼主问的问题刚好对立的方案