OceanBase根据分布式数据库的技术原理,在建表的时候,需要指定分区键,有业务相关的数据表都需要带有同样的字段,才能充分发挥数据库的性能,比如要制作一个电子商务管理系统,可以按照用户登录账号作为分区键,来保存用户购物车、用户收藏夹、用户订单、用户订单的物流,每个表都带有 user_id 字段,这样在表连接的时候,就不会出现跨分区跨服务器查询的问题,然而对于没有明确分区键的业务怎么去使用分布式数据库呢?比如一个进销存系统,要管理物料、客户、供应商、出入库数据、现有量、采购合同、采购订单、销售合同、销售订单、预收款、应收款、销售发票、实际收款、预付款、应付款、应付发票、实际付款、员工报销单、无形资产、固定资产,并且要在同一个系统里面实现不同核算单位的多账套数据屏蔽和报表的合并查询、公司间交易的采购转销售、公司间交易的应收应付对冲,在这种情况下,数据表比较多并且关联关系没有简单明确的分区键,应该怎么去做才能顺利的基于分布式数据库来搭建系统呢?这个是我整理的文档,里面有两个示例SQL,虽然确实很长,但是这种写法在现有的系统中确实很常见
对于没有明确分区键的业务,您可以考虑采用其他的分区策略。比如,可以根据业务的特点,将数据按照时间、地理位置、业务类型等进行分区。在建表时,可以将这些分区键作为表的列进行定义,并将其作为分区键进行分区。这样做的好处是可以充分发挥分布式数据库的性能,同时也能满足业务的需求。
另外,对于多账套数据屏蔽和报表的合并查询、公司间交易的采购转销售、公司间交易的应收应付对冲等需求,您可以考虑使用分布式事务来实现。分布式事务可以保证多个节点之间的数据一致性,并且支持跨节点的事务操作。在具体实现中,您可以使用类似于分布式锁的机制来保证数据的一致性,同时也可以使用类似于分布式消息队列的机制来实现跨节点的数据传输和交换。
最后,关于您提到的示例SQL,虽然确实比较长,但是这种写法在实际的业务场景中确实很常见。在实际开发中,您可以根据具体的业务需求和系统架构来进行优化和调整,以达到更好的性能和可维护性。
你这怕是join了都不止100张表了,光是把这些表给join起来就费不少劲吧,你们现在用的啥数据库啊,为了实现某一个业务join这么多的表,感觉已经是过度设计了,报表多关联一些表能想通,他这个是业务关联这么多表,OB也有全局表 不更新的很频繁的是不是可以建立成全局表,再看下还有多少大表怎么分组,此回答整理自钉群“[社区]技术答疑群OceanBase”
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。