My statement will be unpopular fact. My workplace using gorm for application with avg 3k qps. Even at some point its exponentially increase to around 50k (campaign event). Its a big project. Never had issue caused by gorm specifically.
On Thu, Jan 9, 2025, 9:41 PM Mike Schinkel <m...@newclarity.net> wrote: > On Jan 8, 2025, at 11:56 PM, Henry <henry.adisuma...@gmail.com> wrote: > > I am not aware of any SQL wrapper in Go, but then I didn't look hard > enough. At work, we implemented our own SQL wrapper for a few databases we > commonly work with. In .Net, you have LINQ, but LINQ is a query-only > language. But the idea is the same, which is to provide a common interface > when working with data sources. That way you can switch databases with > minimal changes to your project code. Working with SQL and its dialects and > dealing with each database's quirkiness is quite time consuming. > > > As someone with off-and-on SQL experience on a variety of platforms > starting in the mid 90's, I completely empathize with your concerns. I > even designed my own such approach last year, but never implemented it > because the scope was too intimidating, and I did not know how to support > myself while developing it. > > The problem with the concept, however, is that although the concept has > real value there are no known implementations of said concept[1] other than > (at least one) internal solution(s) as you mention, where the sponsor also > owns the cost of all maintenance and enhancements. But not being in the > business of selling such a solution[2] means not enough use-cases are > tested ensuring the design is not really robust and is not broad enough to > cover all reasonable use-cases. > > I would love to see someone produce such a solution. However, given the > fact that we have had SQL for right at 50 years[3], I am not holding my > breath. #fwiw > > -Mike > > 1 — LINQ being an admitted subset and with a design that requires > embedding into the language is unfortunately not a complete solution and it > couples concerns. > > 2 — This is the core vs. context problem that Geoffrey Moore wrote about > where companies should invest in R&D for their core businesses vs all those > things they need to do to deliver on their core, aka "the context." IOW, > unless one's business is to sell an agnostic SQL wrapper solution, > investing in developing a SQL wrapper solution is just an expense and will > likely never produce a world class product (with the caveat being if it is > open-sourced — like React — but then internal-only solutions by-definition > are not.) > > 3 — https://en.wikipedia.org/wiki/SQL#History > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/9A49DA81-78F2-4C22-8B3D-8E9A35CA3D83%40newclarity.net > <https://groups.google.com/d/msgid/golang-nuts/9A49DA81-78F2-4C22-8B3D-8E9A35CA3D83%40newclarity.net?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CA%2BBFoMmNrRYoawbCqUF4vk2NFcc9a3i5pF-fcdH%3Dw2xhuDqOTg%40mail.gmail.com.
