I was under the impression that the creators of
dplyr are familiar with SQL  and did (and still do) use it as a direct inspiration [2,3]. But SQL is not very well suited for data analysis  so the design of
dplyr is about taking the good parts but reformulating other parts with data analysis in mind [5,6].
(not speaking with authority, but I have sources!)
That said, I am very familiar with SQL
see: Disagree with Hadley's comment about databases
SQL is the inspiration for dplyr’s conventions, so the translation is straightforward
Thanks to Kirill Müller, dplyr has a new experimental family of row mutation functions inspired by SQL’s
UPSERT , and
4: for example https://blog.exploratory.io/why-sql-is-not-for-analysis-but-dplyr-is-5e180fef6aa7
If you’ve used a database before, you’ve almost certainly used SQL. If so, you should find the concepts in this chapter familiar, although their expression in dplyr is a little different. Generally, dplyr is a little easier to use than SQL because dplyr is specialised to do data analysis
[...] dplyr maybe might be better than SQL in some ways. But I think it is, because it's trying to solve a much, much smaller problem than SQL is trying to solve. [...] I think you can rethink the language and the interface, and of course, we've learned a bunch about programming and programming languages and the 40 years since SQL has been around. So I think there's some really nice things about dplyr that just make life a little bit more pleasant.