这里也有matz啊

trigger或check constraint都可以吧

ALTER TABLE book_shelfs ADD CONSTRAINT books_count_check CHECK (
   books_count <= 10
);

有点乱

表姐堂姐什么也算姐妹吧...

其实主要是思维方式的改变

不是说用了restful框架写出来的API接口就是restful接口，restful带来最大的认知是如何抽象资源。能摆脱View驱动是json-api和GraphQL的进化方向。如果没有这个认识，即使用GraphQL也可以写出狗屎一样的接口，并且自己完全意识不到那是狗屎。

就是缓冲一下咯，如果简单的msg插入也是瓶颈的话，确实不适合。其实pgmq可以使用multi node模式的，也没问题。

https://ruby-china.org/topics/25579

每家公司每月限发布一条招聘信息，30 天后可以重新发布，多个职位的招聘信息请合并到一个帖子中发布

looks good.

解决不了你的问题

榜上没有的是最值得学习的...

哇 graphql+pg+ RN = awesome.

那再加一个mutate和re-consuming

pg 9.5和mysql8之后有了skip locked，锁不是一个大问题。但不同的消息队列的功能特性差异很大，例如：

所以，如果你的应用场景需要 持久化+延迟队列+优先级，那么rabbitmq和kafka都满足不了，这些逻辑只能要应用层去实现。

db做队列性能一定不如流行的mq，但也有其他优势。

Auto Vacuum是可以定期清理的，只是磁盘空间会占用，不会对查询影响：https://www.postgresql.org/docs/9.5/routine-vacuuming.html

新玩具~~

感觉ActiveJob没啥用

delayed_job已经不支持rails 5了吧，跑不起来...和DJ比有点欺负人啊，毕竟DJ是上个世纪的东西了。pgmq真的非常有意思，这个坑够填一阵子了

1. 实现机制不一样，que使用的是advisory locks，pgmq使用的是PostgreSQL 9.5's SKIP LOCKED feature.
2. que的实现是有问题的，参考：https://brandur.org/postgres-queues
3. 其实pgmq的目标不止是做background job，上面列表里的功能有一些只有sidekiq pro才提供，但其实对于一些应用非常有必要
4. 还有就是pgmq可以其他语言使用的，不局限在Ruby上

https://www.holistics.io/blog/how-we-built-a-multi-tenant-job-queue-system-with-postgresql-ruby/

urgent_client单独启一个worker咯

fuzzystrmatch 是default，但和这个还是有点差异

fixed.

release as a pg extension: https://github.com/hooopo/pg-fuzzywuzzy