为什么你们要把 sql 当 nosql 用？

• 資深大佬 : Maboroshii

  那主能分享下在项目中用了关系数据库的哪些好处呢

• 資深大佬 : neoblackcap

  @Maboroshii 事务，联表查询，SQL 语法，维护简单

• 主 資深大佬 : iseki

  @Maboroshii 既然用不上 /用不了，那干脆就别用啊，非抱着 dbms，啥特性也不敢用，最后性能还是不够了得分库分表……折腾了有点

• 資深大佬 : wangyanrui

  因为相对来说，这玩意大家掌握的更好一丢丢

• 資深大佬 : totoro52

  不结合业务场景说这些太耍流氓了

• 資深大佬 : xiangyuecn

  占问一下，java，spring 的 @Component 组件实现类的成员函数里面，怎么拿到当前调用本方法的 spring 代理对象？ this 肯定不能用的

• 主 資深大佬 : iseki

  @totoro52 u1s1，qs

• 主 資深大佬 : iseki

  @xiangyuecn 自己注入自己试试

• 資深大佬 : xiangyuecn

  @iseki #8，没试过，下次试一下，原来还可以这样玩

• 資深大佬 : fkdog

  @xiangyuecn 解决的路子不对。
  针对事务嵌套事务的处理，spring 有专门的事务传播机制可以选择。
  可以在 @Transactional 注解里设置传播机制。

• 資深大佬 : xiangyuecn

  @fkdog #10 跟传播不传播好像没有关系，代理对象上调用方法，和 this 调用方法，区别可不是一点。

  当你发现 @Transactional 注解的新事务没有开启，应该回滚的被提交，应该提交的被回滚，那就会很奇怪。

  最终还是注解的锅，脱离了代理对象，注解不一定能被 spring 处理；如果手动控制事务，想开启开启，想提交提交，想回滚回滚，只要没有提交就是回滚，这些问题都可以避免。用注解来实现事务管理真不是一个好的想法，只能说是省事

  可惜手动控制事务，代码繁琐，浪费生命

• 資深大佬 : vencent

  因为非 RDBMS 公司没人维护基础架构，所以。。。

• 資深大佬 : Jooooooooo

  mysql 运维成熟, 稳定性高.

• 資深大佬 : ychost

  @xiangyuecn AspectJ 的的 Gglib 模式 this 和 代理对象就一样了，在 EnableAspectJAutoProxy. proxyTargetClass 开启

• 資深大佬 : xuanbg

  @xiangyuecn @Transactional 注解需要注意的就是调用的方法不要在同一个类，另外就是不要被同样有 @Transactional 注解的类调用或调用 @Transactional 的方法。这应该很容易做到

• 資深大佬 : ychost

  用其它数据库出了问题都找不到答案，用 RDBMS 资料这块至少很多，而且也提供 JSON 的支持

• 資深大佬 : xuanbg

  @iseki 我也很好奇那些怕性能问题不用 join 的，为啥不干脆用 nosql 算了。。。关系型数据库就是要联表的呀，不联表查询哪来的关系？不存在关系用的哪门子 sql ？

• 資深大佬 : geekboy

  @xuanbg 不是不用 join，是不要 join 太多表，join 大表要建好索引，性能问题当然要引起重视。

• 資深大佬 : CRVV

  原因之一是关系型数据库本身更可靠或者性能更好。

  比如性能比较。当然这公司是搞 PostgreSQL 的，结果可能有偏差。
  https://www.enterprisedb.com/blog/comparison-mongodb-vs-postgresql

  PostgreSQL 更可靠应该没什么悬念。

• 資深大佬 : ReferenceE

  Transaction 不就一个要么不执行，要么全部执行么

• 資深大佬 : fkdog

  @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 方法，玩意他们调用了然后创新了一条新纪录可能也不是他们自己的本意。

• 資深大佬 : oneisall8955

  @xiangyuecn springcontextutil

• 資深大佬 : xiangyuecn

  @fkdog #21 谢谢

• 資深大佬 : BeautifulSoap

  那么既然 lz 这么懂的话，能不能回答下我这个帖子的需求，该用什么 nosql ？ mongodb 是不行的，孱弱的搜索和建索引能力

• 資深大佬 : BeautifulSoap

  帖子忘贴了

  https://www.v2ex.com/t/762196

  除了使用 sql 预留字段或者 json，请问上面这需求还有什么解决办法？

• 資深大佬 : zjsxwc

  除了不用外键、不用存储过程、对公业务不 join 多个表外，其他的特性我都用

• 資深大佬 : mtrec

  cp 数据库跟 ap 数据库有什么好比的 哪个合适上哪个 没瓶颈别出错就行 架构都是慢慢演变的

• 資深大佬 : Rocketer

  几年前的测试结果，拿 PostgreSQL 当 nosql 用，性能比 mongo 还好，也不知道这几年 mongo 提升了没有

• 資深大佬 : msg7086

  因为有人运维啊，因为 ORM 现成的框架啊，因为万一要用到关系的时候不用推翻重来啊，等等。

• 主 資深大佬 : iseki

  然而我说的是那些折腾分表分库的，为什么不一步到位 nosql

• 資深大佬 : LokiSharp

  @iseki NoSQL 综合性能不如 SQL
• 資深大佬 : qwerthhusn

  坏的医美，暴殄天物；好的医美，锦上添花，笔补造化。。

• 資深大佬 : beichenhpy

  @xiangyuecn 不知道你是怎么使用的，我这边只要加上注解，就算是同一个类中的调用，在各个地方用 Int i = 1/0;都是可以回滚的

• 資深大佬 : NULL2020

  @xiangyuecn #6 AopContext.currentProxy()

• 資深大佬 : passerbytiny

  看了主的主贴、追加、回复，不知道主再说啥。

  大概有一点可以确定，主想用 nosql 替代 sql 。不要有这样的想法，会很惨的。第一，nosql 虽然叫 nosql，但它真得不是 sql 的反义词，而是补充（ RDBMS 的反义词是 ODBMS，这玩意有人尝试过，至今没有成功）。第二，事务，还真是具有一票否决权，目前只有 RDBMS 能够在性能期望内完全满足事务的所有原则。

  最后再提醒一下，分库分表，这可是实实在在面向对象领域的事，sql 是实现它而不是决定它，你就算换了 ODBMS 或者全部使用 nosql，也是避免不了的。

• 資深大佬 : no1xsyzy

  因为 SQL 搞了很久，优化也都做得很足

  @BeautifulSoap 我先盲猜一个图数据库和一个 redis （
  不过，我觉得这不是数据库的事儿。

• 資深大佬 : hjosama

  你好可爱哦，喜欢你

• 資深大佬 : hjosama

  看了你的博客，感觉真的好可爱！似乎像你喜欢 miku 那样，我也喜欢上你了呢，好可爱！

• 資深大佬 : hjosama

  iseki 我好喜欢你呢… 到底是个怎样的男孩子呢…

• 資深大佬 : hjosama

  iseki 酱在哪个城市呢… 想交朋友…

• 資深大佬 : hjosama

  原来可爱到如此程度的 iseki 酱是个买房了的中年大叔呢 爱情还没开始就凋零了…

• 資深大佬 : fengxianqi

  上在干嘛。。

• 資深大佬 : hjosama

  我已经爱上 iseki 酱了 无法自拔了 等回复唔

• 資深大佬 : hjosama

  感觉喜欢热度稍微下降了一点点，因为十几分钟还没回复，大概是因为被 iseki 酱的可爱一时上头了呢

• 資深大佬 : Macolor21

  @iseki
  说实话我技术不够好，看不懂你的吐槽点，对我来说 NoSQL 一般键值对存储和文档存储？
  然后你说的分库分表，我司有个需求：一个 SaaS 系统，每一个客户拥有一套完整的数据库（用户，数据，分类，客户端 balabala 一堆表），每个客户存储的数据量不一（根据付费等级而定）。因为是 SAAS，所以应用程序是共用同一套，只是底层存储不一样。这种需求的话，如果不以客户分库（目前是 SELECT xx FROM client[xx].user ） 的话，我想不出来有什么更好的解决方案。（可能给行加个客户端列？那这样底层的数据聚集是应该以客户聚集，还是表本身呢？如果以表本身，那查一个客户德批量查询，估计的 N 多次寻道…）

• 資深大佬 : magese

  @hjosama ???

• 資深大佬 : JasonLaw

  @passerbytiny #35 连自己想要表达的东西都说不清楚，但是却有那么多人回复，真是不懂。

• 資深大佬 : JasonLaw

  而且回复里面也掺杂了好多无关的东西，就不能自己新建个主题吗？

• 資深大佬 : namelosw

  因为 Postgres 一把梭省事。

  实在遭不住再换 Cassandra 之类暴力的，运维操蛋。

• 資深大佬 : tairan2006

  现在不怎么谈 NoSQL 了吧，像一般的 MPP 数据库甚至 ElasticSearch 这种，现在都兼容 sql 了，大融合不可避免。

  至于分库分表，现在还有这么搞的？ OLTP 就直接用 tidb 啊…

• 資深大佬 : letking

  请教主，折腾分表分库具体是指什么操作？如果数据到了需要分表的量级，那有什么 nosql 数据库可以更简单的处理呢？

• 資深大佬 : chenqh

  因为 mysql 历经考验，用的人比 mongo 多

• 資深大佬 : Lemeng

  前面几是什么东东

• 資深大佬 : ThanksSirAlex

  我就是不喜欢用 mongodb，至少以目前的开发经验来说没有经历过哪家公司用的非常好的，就仗着人家没有固定的 schema 数据就 XJB 乱存，然后全在代码里面加各种操作，我宁可老老实实用关系型数据库，每个字段的意思给我写写清楚，当然，这里说的是工程代码，自己写的代码随便怎么玩都行。

• 資深大佬 : bthulu

  mysql 出的早, 用的人多, 没动力换 mongo. 等 80 后 90 后这一批人都下岗了, 自然就都是 mongo 一把梭了

• 資深大佬 : cmai

  @xiangyuecn 跟注解没有关系，同类调用不经过代理只是传播特性不生效而已，事务还是会展开的，但是你自定义的传播特性就会丢失，我这边如果没有特殊的业务需求需要用到自定义的传播特性是不管的，如果要用到自定义传播特性，那就在本类自己注入自己

• 資深大佬 : moen

  用过 Postgres 的都说好

• 資深大佬 : EridanusSora

  。。点进来发现要素过多

• 主 資深大佬 : iseki

  。。。一开始发帖时确实疏忽了…表达的很不准确，主要是吐槽分库分表，性能不够就分库分表，rdb 的功能废了大半。

• 主 資深大佬 : iseki

  @passerbytiny 难道不是很多 rdb 出现单点的性能问题同时不好利用其本身的分布式分区机制才分库分表的吗？
  既然这样为什么不去用本身把这些问题处理的很好的那部分 nosql，毕竟分完表，rdb 的 r 很多也都废了
  事物的问题，我一开始确实没有深入考虑，的确目前没有现成的，像现有 sql 数据库那样好用的…

• 主 資深大佬 : iseki

  @Macolor21 显然我吐槽的不是你说的这种分库的场景…每个客户端数据没啥关系分成多个非常合理

• 資深大佬 : Nillouise

  用过 aws 的 dynamodb，确实自带的分区功能就不错了，之后看看 dynamodb 能不能蚕食 mysql 吧。

  如果 mysql 的优势只是在事务的话，那应该有机会被取代的。

• 資深大佬 : stabc

  分区就变 NOSQL 了？什么逻辑？ NOSQL 本身也分区啊