这是一个创建于 1893 天前的主题，其中的信息可能已经有所发展或是发生改变。
sql 的好处一点没沾着，坑全要踩一遍，传统 dbms 这么多功能就用了个事务，有人可能还不注意用不对…
第 1 条附言 · 2021 年 4 月 9 日
我的标题不严谨，大家误会了，我是想说那些折腾分表分库的…至于 rdb 本身的类似 nosql 的特性，如 json，我也很喜欢用
第 2 条附言 · 2021 年 4 月 9 日
突然发现被移到 nosql 节点了…
一开始的帖子正文的确很多话没有说清楚。
主要吐槽质疑的是：处于单表单库性能原因，同时不好利用数据库本身的分区机制规避性能问题，因此将本来属于一个集合的数据按哈希或是主键区域分布到多个表多个库的行为。
问题：破坏了关系型数据库的设计模式，导致数据库本身的检查、关联查询等功能全部报废…可以说除了一个事物，什么好处都没用到；至于运维，可能是我经验有限，我实在不认为这个规模的企业不能运维好一组 nosql
起初的帖子写的不够完整清晰的确失误
 |
1 Maboroshii 2021 年 4 月 8 日 1
那楼主能分享下在项目中用了关系数据库的哪些好处呢 |
 |
3 iseki 2021 年 4 月 8 日 via Android@Maboroshii 既然用不上 /用不了，那干脆就别用啊，非抱着 dbms，啥特性也不敢用，最后性能还是不够了得分库分表……折腾了有点 |
 |
4 wangyanrui 2021 年 4 月 8 日 via iPhone 1
因为相对来说，这玩意大家掌握的更好一丢丢 |
 |
5 MIUIOS 2021 年 4 月 8 日 1
不结合业务场景说这些太耍流氓了 |
 |
6 xiangyuecn 2021 年 4 月 8 日占楼问一下，java，spring 的 @Component 组件实现类的成员函数里面，怎么拿到当前调用本方法的 spring 代理对象？ this 肯定不能用的🐶 @Transactional 注解对小白来讲，说好听点就是真省事，说难听点就是反人类 目前我为了保证需要事务环境的方法一定可以开启事务，函数里面强制检查了一遍是否是在事务环境里面；当不需要事务的方法里面调用同一个类里面另一个会新开事务的方法，不需要事务的这个方法我就加一个 self 参数（当前类的接口类型，就是谁调的这个方法就把谁传进来），通过 self 来调用新开事务的方法，多加这个参数仅仅是为了获取代理对象，太难受了，人家的文档又看不懂😂 应该会有一个什么 SpingXXXUtils.currentBean() 之类的东西可以拿到当前这个类接口的代理对象吧，可惜我太菜🐶 求指点，指指点点也行 |
|
11 xiangyuecn 2021 年 4 月 8 日@fkdog #10 跟传播不传播好像没有关系，代理对象上调用方法，和 this 调用方法，区别可不是一点。 当你发现 @Transactional 注解的新事务没有开启，应该回滚的被提交，应该提交的被回滚，那就会很奇怪。 最终还是注解的锅，脱离了代理对象，注解不一定能被 spring 处理；如果手动控制事务，想开启开启，想提交提交，想回滚回滚，只要没有提交就是回滚，这些问题都可以避免。用注解来实现事务管理真不是一个好的想法，只能说是省事 可惜手动控制事务，代码繁琐，浪费生命 |
 |
12 roccaplover 2021 年 4 月 8 日 1
因为非 RDBMS 公司没人维护基础架构，所以。。。 |
 |
13 Jooooooooo 2021 年 4 月 8 日mysql 运维成熟, 稳定性高. |
 |
14 ychost 2021 年 4 月 8 日 1
@xiangyuecn AspectJ 的的 Gglib 模式 this 和 代理对象就一样了，在 EnableAspectJAutoProxy. proxyTargetClass 开启 |
|
16 ychost 2021 年 4 月 8 日用其它数据库出了问题都找不到答案，用 RDBMS 资料这块至少很多，而且也提供 JSON 的支持 |
 |
17 xuanbg 2021 年 4 月 8 日@iseki 我也很好奇那些怕性能问题不用 join 的，为啥不干脆用 nosql 算了。。。关系型数据库就是要联表的呀，不联表查询哪来的关系？不存在关系用的哪门子 sql ？ |
 |
20 ReferenceE 2021 年 4 月 8 日 via AndroidTransaction 不就一个要么不执行，要么全部执行么 |
 |
21 fkdog 2021 年 4 月 8 日 4
@xiangyuecn 跟注解没关系。我不知道你的需求是什么才会想到这么膈应人的方法。我提供一个场景不知道符不符合你的需求。 某一个 Service 提供 findByName 方法，findByName 出于某种原因里边有个需求，如果没有查询到某个 Name，那么就创建一条这样的记录，也就是说 findByName 需要调用同 service 下的 create 方法。但是由于通过 this.create 方法，是没有走 spring 的事务增强的，那么很容易导致问题。那么你的解决思路是通过 Spring 的 AopUtils 来获取 this 在 spring 容器中增强过的 bean 。 你的这个想法的确是可以解决你的需求，但是这不是一个好的解决思路。 我更倾向于 findByName 和 create 方法在某一层进行聚合，而不是在 findByName 里调用 create 方法。或者你不想加入聚合层，你可以直接在 Sevice 创建一个新方法 findOrCreat()来聚合这两个 findByName 和 create 方法，然后你在 findOrCreat 上边打上 @Transactional 注释来控制内部嵌套事务的传播性，方便你更细粒度的处理事务提交和回滚。而且 findByName 能更好的专注于方法名所提供的功能，因为其他人去调用你的 findByName 时他们是不清楚你里边还有调用了 create 方法，玩意他们调用了然后创新了一条新纪录可能也不是他们自己的本意。 |
 |
24 BeautifulSoap 2021 年 4 月 8 日那么既然 lz 这么懂的话，能不能回答下我这个帖子的需求，该用什么 nosql ？ mongodb 是不行的，孱弱的搜索和建索引能力 |
 |
26 zjsxwc 2021 年 4 月 8 日 via Android除了不用外键、不用存储过程、对公业务不 join 多个表外，其他的特性我都用 |
 |
27 mtrec 2021 年 4 月 8 日 via Android 1
cp 数据库跟 ap 数据库有什么好比的 哪个合适上哪个 没瓶颈别出错就行 架构都是慢慢演变的 |
 |
28 Rocketer 2021 年 4 月 9 日 via iPhone几年前的测试结果，拿 PostgreSQL 当 nosql 用，性能比 mongo 还好，也不知道这几年 mongo 提升了没有 |
 |
29 msg7086 2021 年 4 月 9 日 via Android因为有人运维啊，因为 ORM 现成的框架啊，因为万一要用到关系的时候不用推翻重来啊，等等。 |
|
30 iseki 2021 年 4 月 9 日 via Android然而我说的是那些折腾分表分库的，为什么不一步到位 nosql |
 |
32 qwerthhusn 2021 年 4 月 9 日坏的医美，暴殄天物；好的医美，锦上添花，笔补造化。。 |
 |
35 passerbytiny 2021 年 4 月 9 日 via Android 2
看了楼主的主贴、追加、回复，不知道楼主再说啥。 大概有一点可以确定，楼主想用 nosql 替代 sql 。不要有这样的想法，会很惨的。第一，nosql 虽然叫 nosql，但它真得不是 sql 的反义词，而是补充（ RDBMS 的反义词是 ODBMS，这玩意有人尝试过，至今没有成功）。第二，事务，还真是具有一票否决权，目前只有 RDBMS 能够在性能期望内完全满足事务的所有原则。 最后再提醒一下，分库分表，这可是实实在在面向对象领域的事，sql 是实现它而不是决定它，你就算换了 ODBMS 或者全部使用 nosql，也是避免不了的。 |
 |
37 hjosama 2021 年 4 月 9 日你好可爱哦，喜欢你 |
|
38 hjosama 2021 年 4 月 9 日看了你的博客，感觉真的好可爱！似乎像你喜欢 miku 那样，我也喜欢上你了呢，好可爱！ |
|
39 hjosama 2021 年 4 月 9 日iseki 我好喜欢你呢... 到底是个怎样的男孩子呢... |
|
40 hjosama 2021 年 4 月 9 日iseki 酱在哪个城市呢... 想交朋友... |
|
41 hjosama 2021 年 4 月 9 日原来可爱到如此程度的 iseki 酱是个买房了的中年大叔呢 爱情还没开始就凋零了... |
|
43 hjosama 2021 年 4 月 9 日我已经爱上 iseki 酱了 无法自拔了 等回复唔 |
|
44 hjosama 2021 年 4 月 9 日感觉喜欢热度稍微下降了一点点，因为十几分钟还没回复，大概是因为被 iseki 酱的可爱一时上头了呢 |
 |
45 Macolor21 2021 年 4 月 9 日@iseki |
 |
48 JasonLaw 2021 年 4 月 9 日 via iPhone而且回复里面也掺杂了好多无关的东西，就不能自己新建个主题吗？ |
 |
49 namelosw 2021 年 4 月 9 日因为 Postgres 一把梭省事。 实在遭不住再换 Cassandra 之类暴力的，运维操蛋。 |
 |
50 tairan2006 2021 年 4 月 9 日现在不怎么谈 NoSQL 了吧，像一般的 MPP 数据库甚至 ElasticSearch 这种，现在都兼容 sql 了，大融合不可避免。 至于分库分表，现在还有这么搞的？ OLTP 就直接用 tidb 啊… |
 |
51 letking 2021 年 4 月 9 日请教楼主，折腾分表分库具体是指什么操作？如果数据到了需要分表的量级，那有什么 nosql 数据库可以更简单的处理呢？ |
 |
52 simple2025 2021 年 4 月 9 日因为 mysql 历经考验，用的人比 mongo 多 |
 |
53 Lemeng 2021 年 4 月 9 日前面几楼是什么东东 |
 |
54 ThanksSirAlex 2021 年 4 月 9 日我就是不喜欢用 mongodb，至少以目前的开发经验来说没有经历过哪家公司用的非常好的，就仗着人家没有固定的 schema 数据就 XJB 乱存，然后全在代码里面加各种操作，我宁可老老实实用关系型数据库，每个字段的意思给我写写清楚，当然，这里说的是工程代码，自己写的代码随便怎么玩都行。 |
 |
55 bthulu 2021 年 4 月 9 日mysql 出的早, 用的人多, 没动力换 mongo. 等 80 后 90 后这一批人都下岗了, 自然就都是 mongo 一把梭了 |
 |
56 cmai 2021 年 4 月 9 日 1
@xiangyuecn 跟注解没有关系，同类调用不经过代理只是传播特性不生效而已，事务还是会展开的，但是你自定义的传播特性就会丢失，我这边如果没有特殊的业务需求需要用到自定义的传播特性是不管的，如果要用到自定义传播特性，那就在本类自己注入自己 |
 |
57 moen 2021 年 4 月 9 日用过 Postgres 的都说好 |
|
59 iseki 2021 年 4 月 9 日 via Android。。。一开始发帖时确实疏忽了…表达的很不准确，主要是吐槽分库分表，性能不够就分库分表，rdb 的功能废了大半。 |
|
60 iseki 2021 年 4 月 9 日 via Android@passerbytiny 难道不是很多 rdb 出现单点的性能问题同时不好利用其本身的分布式分区机制才分库分表的吗？ |
 |
62 u2r1Hqo6HExmNsrt 2021 年 4 月 9 日用过 aws 的 dynamodb，确实自带的分区功能就不错了，之后看看 dynamodb 能不能蚕食 mysql 吧。 如果 mysql 的优势只是在事务的话，那应该有机会被取代的。 |
 |
63 stabc 2021 年 4 月 9 日分区就变 NOSQL 了？什么逻辑？ NOSQL 本身也分区啊 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
