例如这种把构成 sql 语句都放在数据库中,后台只负责提供增删改查的 4 个 api,由前台传入特定的 apiid 就可以达到各种对象的增删改查的数据库设计的方案...大概怎么查到之类的设计方案
1
jjx 2016-12-17 10:29:07 +08:00
这种 api 是给人用的吗
|
2
xudaolong OP @jjx 只要数据库配好 指定了 apiid 然后前台负责给特定的接口例如 /select 带上指定的 apiid 参数 就能达成这个对象的查询效果了...
|
3
ihuotui 2016-12-17 10:47:00 +08:00 via Android
你直接让前端传送 sql 就好了
|
4
RoshanWu 2016-12-17 10:49:27 +08:00
前端动 sql 恐怕很少吧。还不如用 Graphql 加一层。
|
5
annielong 2016-12-17 10:49:51 +08:00
前端直接传 id 和查询类型不就行了,其他后台来生成 sql ,一般都是这样做的吧
|
6
wmhx 2016-12-17 10:50:17 +08:00
为了设计而设计, 设计这种 sql 的 sql 有意思么?
就设计 2 个字段,id 和 sql,传 id 和参数执行 sql 不就行了? |
7
xudaolong OP @wmhx 这种设计目的是 之后程序不用改动 只需要在数据库进行添加并附加一个 apiid 就会有新的对象的 增删改查的...
|
8
likai 2016-12-17 10:59:15 +08:00
设计成这样.还不如直接让前端传 SQL
|
9
dayjgut 2016-12-17 11:13:14 +08:00 via iPhone
我的天...
1. 你每次数据库操作都需要额外的一次 DB 查询 2. 由于问题 1 ,所以做缓存是必然的了,那为什么不直接在应用层面去设计,很多 ORM 框架都可以提供 sql 和 id 的映射关系并在运行时决定执行哪个 sql 的 3. 你确定服务端的业务逻辑仅仅用 sql 就可以实现吗,明显不行啊.... 另外,你的 sql 参数怎么传入?多个 sql 执行顺序如何协调? |
10
Miy4mori 2016-12-17 12:20:06 +08:00 via Android
怕不是遇到复杂业务连事物都没有了, mongodb 适合你……, rdb 不适合你
|
11
fy 2016-12-17 16:37:16 +08:00
|
12
SoloCompany 2016-12-18 12:27:36 +08:00
你这个定义应该放内存里而不是数据表里
如果真的要做到可配置,那么放个某个配置文件里面就可以了 至于喷性能的是什么心态?实现上难道不应该 100%放内存,难道每次 api 解释还查数据库? |
13
xudaolong OP @fy @SoloCompany 其实放配置文件到数据库 主要的目的是 不修改或添加代码的情况下 进行新对象接口 api 的提供,给运维人员带来方便.当然地,第一次查询或者服务器启动的时候就可以对这个 api 视图进行缓存...
|