cool

支持了通过 rails-erd 导入 https://github.com/drawerd/drawerd

有道理

理论上可以 但我没想到这个需求的应用场景 就没做成多对多

本来设想的场景是用来划分微服务的参考 一个表只能属于一个服务

没想好交互怎么做，其实最近想把 rails-erd 那个 gem 改一下，配置一下 drawerd 的 api key，就可以直接把表和关系传到 drawerd 上

thanks，已修，但是 github 挂了，没发布...

google 自动生成的

需要外包么

saas 只能自己提供接口咯

代码写的不多但想得多

和 graphql subscription 效果有点类似

如果能利用各种前端组件的生态的话 确实不错的方案

静态站 都不需要服务器 github page 之类就行

增加了根据列名称 自动产生关系的机制，应该方便很多了。

users.account_id -> accouts.id

mysql 导入也支持了：https://help.drawerd.com/importing/importing-mysql

base xx

我觉得所有画框的问题是 如果你的项目上了点规模，一般大项目 300-500 张表，中等也得 100+ 吧，画框就是灾难，左侧那个 DSL 挺酷，但也有一些门槛，语法记住的难度和你记住 SQL DDL 语句差别不大

试用过，目前来说应该是同类中做的比较好的，唯一我觉得不太满意的地方是那个画布其实很难用，在画布上拖动实体框来生成一个美观的 ER 图，这个难度和华容道类似，等我把 @liprais 说的从 information_schema 里提取数据表和外键的功能加上之后，会比 dbdiagram 好用很多。

高产

rails-erd 那个 gem 其实挺不错，问题是如果整个项目都生成之后，一个大的 pdf 几乎没法看，所以 drawerd 引入了分组功能，可以按模块去标记，然后按模块过滤出来一个小的 ERD

只能 mysql 并且单机用还是有点不方便，drawerd 的目标是协同工具，比如可以生成 svg url 分享到项目管理工具里：

ps. ruby-china 还不支持插入 svg 图片

https://github.com/exAspArk/batch-loader#restful-api-example

https://weibo.com/1773116334/ID7ewfvHi?type=comment

转一个今天看到的：

又看到好几个网友让我扯扯微服务架构，在前面谈到后端技术体系的微博时，有说到中间件那一层的技术就是现在所谓的微服务架构中涉及的中间件，就是不想提微服务这个词而已，这条长微博就专门说微服务。

Martin Fowler 开的公司是做技术咨询和外包服务的，最热衷这种新名词了 (不搞点新概念怎么开展新业务)。还有现在的云厂商也很乐于推微服务架构，多好的卖机器卖服务的机会啊，一个原本只用单机部署的系统鼓吹一下搞成微服务拆成 N 个系统后又可以多赚几倍的钱了。

我在传统行业做了 10 几年的企业应用，从地市级到省级系统，只要是面向内部用户的，就没有一个是单体系统满足不了的。微服务架构更适合那种用户规模起来之后的互联网企业，从阿里辞职出来之后，过去 8 年，我再也没参与过基于微服务架构的系统了，因为没有真实的需求。

我当初就是在阿里的中间件团队工作，微服务架构的系统所需要的三架马车全在我们组，包括服务框架、分库分表中间件、消息中间件。这三架马车我就参与了其中两架：服务框架、分库分表中间件。

服务框架当初阿里的叫 HSF，除了最基本的 RPC 功能也有软负载，然后还得有 config server 做服务的注册与发现，搞到后面你还得做一个分布式调用链跟踪系统，为了存储分析调用链中的日志又得引入一整套的大数据领域的技术栈 (当年我们全网每天的调用量是 2000 亿起步)。

现在开源的微服务技术栈可以选用 Apache Dubbo 做 RPC 框架，但是服务注册与发现你还得配合其他的 (比如 Apache Dubbo 官方推荐用 zookeeper)。顺便说个八卦：Apache Dubbo 就是当年在阿里内部跟我们组的 HSF 竞争失败后开源出来的，现在能流行也是无心插柳。自从阿里云这家子公司做成了之后，发现微服务可能是门好生意，Dubbo 这个弃儿居然还有不少用户，然后又把 Dubbo 捡起来了，至于阿里云上面是套 Dubbo 的壳卖 HSF 的企业版还是别的动机我就不多猜了。

除了 Apache Dubbo，现在 java 平台上的微服务技术栈还有比较火的 Spring Cloud 全家桶，我只看过，但没有用过。vert.x 也有微服务的套件，我也没有用到真实的商业系统中。说白了就是没有几个系统需要上微服务。

以上说的还只是解决 API 层面的调用问题，你以为一个采用微服务架构的系统有了 Dubbo 和 Spring Cloud 就够了吗？错错错，session 管理在阿里都需要一个专门的小中间件，为了解决不同系统的消息传递问题，又得引入消息中间件。

还有最难的，数据层的问题怎么搞？你告诉我拆成了 N 个系统后还搞一个共享数据库？逗我玩呢。微服务架构的系统在数据库的层面基本上多是 OLTP 类型的，现在开源成熟的面向 OLTP 的分布式数据库可以说没有，别跟我提国内某司的 NewSQL 数据库，那东西在 OLTP 场景下的性能简直不能看，所以现在还是会用 MySQL 这样的传统关系数据库，然后搭配分库分表中间件来解决微服务架构系统的后端存储问题，拆分后的子系统都有自己的数据库集群。

我在阿里的 TDDL 小组做的 TDDL 就是用来解决 MySQL 的分库分表问题的，直到我辞职时的 2012 年都还不支持分布式事务，现在已经支持了。 TDDL 的性能是做到极致了的，是一种部署在在应用端的分库分表方案，在不涉及分布式事务的情况下基本上接近单机访问 MySQL 的性能。

说完了中间件后，最后再简单谈谈应用服务器，为什么谈这个？跟微服务有关吗？讲真，没有，但是谈到微服务的部署问题就头痛了。当年我在 HSF 小组时还负责应用服务器，有一次要推动 jboss 到 tomcat 的替换工作，因为阿里全网的系统就是拆拆拆之后的小系统组成的，我找了 100 多个系统来测试兼容性 (包括所有的核心系统，比如用户中心、商品中心、交易中心)，因为这些业务系统我都没有参与，所以我根本就没法把这些系统成功部署起来，连各个子系统的单元测试我都没跑通过几个。

所以，听我讲完了这些，你就明白一个单体系统被忽悠成一个微服务架构的系统后会有哪些坑了，要是还无脑往里跳，那就跳吧。

不到万不得已别搞微服务，别为了技术而技术，从码农自私的角度讲，当然希望把系统搞复杂，不难怎么体现自己的价值怎么多拿工资？但是从老板和甲方的角度想，那就是能简单就简单搞，能省钱就绝不乱花，警惕那些把项目当成技术试验田的人，这些人喜欢面向简历编程，哪怕项目失败了，也可以在简历上面大书特书用过微服务架构里的“高级技术”，跳槽加薪不要太爽

直接导出 schemainfo 到 json 应该容易多了

导出 information_schema 和自动猜是两个不错的优化方向，感觉比 ddl parse 要简单

苏州好地方

processon 好像不支持 erd，drawerd 更类似 https://www.lucidchart.com/ xmind 似乎万能，看有 PM 用来提需求，没想到还可以画 ERD...

应该统计的口径是 web，不过现在 app 使用者更多

体验怎么样