Post AZh6aFlNMMUeU2Shea by defanor@emacs.ch
(DIR) More posts by defanor@emacs.ch
(DIR) Post #AZgddkGHWgTDGrEN4C by galdor@emacs.ch
2023-09-12T09:28:19Z
0 likes, 0 repeats
There are reasons to avoid putting too much business logic in the database with user-defined functions, but the most bizarre reason I've seen is that they are hard to test. Your application can execute SQL queries, but somehow you cannot execute one in tests?
(DIR) Post #AZgl2vIQKuxuPeBZOS by bahmanm@mastodon.social
2023-09-12T10:51:19Z
0 likes, 0 repeats
@galdor I think "hard to test" in this context means: there's little to copy-paste from SO 😑
(DIR) Post #AZgmZpqDjqAZ0NFdya by galdor@emacs.ch
2023-09-12T11:08:26Z
0 likes, 0 repeats
@bahmanm This is both sad and very accurate.
(DIR) Post #AZgpO47P88H3fkMtSC by defanor@emacs.ch
2023-09-12T11:39:58Z
0 likes, 0 repeats
@galdor Bizarre-sounding statements often stem from different perspectives; any chance to ask the person who said that for clarification? I imagine the reasons behind that may include misunderstanding on their part, or specifics of the used test suite, such as tracking of test coverage and the setup: a DBMS becomes a runtime dependency for those tests (unless it already was), maybe even multiple DBMS versions, which indeed complicates its execution in tests.
(DIR) Post #AZgqExj1d9gxByBjpg by galdor@emacs.ch
2023-09-12T11:49:31Z
0 likes, 0 repeats
@defanor Is it a recurring argument. I suspect lots of developers are mocking their database in tests which is an incredibly bad idea.
(DIR) Post #AZh6aFlNMMUeU2Shea by defanor@emacs.ch
2023-09-12T14:38:08Z
0 likes, 0 repeats
@galdor Sounds plausible, and in that case one may view a database as a separate component: then the interaction is not for unit testing to test, but rather for integration or system testing, which may be not something a given programmer does. Business logic moved into a database can still be unit-tested, but possibly requiring a different test suite. Though it is just a speculation, best to ask those who make that argument the next time it will surface.
(DIR) Post #AZh6bpgpGr5GCJ5SAS by louis@emacs.ch
2023-09-12T14:44:48Z
0 likes, 0 repeats
@defanor @galdor Remotely connected topic. We're using a web service from a 3rd party to calculate prices for acommodations based on Arrival date and no. of nights. For 300 objects their webservice took 30 seconds (they use M$ technology -> ASP.NET + SQL Server).I complained and now they sent me their raw database as JSON a la "do it yourself you bastard" :-).Now I unmarshal the whole thing into a Go struct. Price calculation for the same number of objects now takes: 840µs. Yes, under one millisecond.The world is bright when you are allowed to use the right tool for the job.
(DIR) Post #AZh6dcRPV3htgdjD3A by galdor@emacs.ch
2023-09-12T14:50:49Z
0 likes, 0 repeats
@louis @defanor Your argument is that fast application code is better than slow database functions. I cannot really argue ;)
(DIR) Post #AZh7GHeOjTLqV3Eva4 by louis@emacs.ch
2023-09-12T15:00:10Z
0 likes, 0 repeats
@galdor @defanor Modern programming languages are made for fast computation, databases are made for storing big amounts of data and fast access.I was once a total fan of "put everything in stored procedures". The disadvantages are obvious and many. Testing becomes a nightmare.I can see that there are some rare valid use cases. I.e. a big corporation that has to make sure that devs don't mess directly with the data. Makes sense here, but they have billions to spend for resources to manage that.Let the database do its job, and put computing into application code. That works out well for the rest of us.
(DIR) Post #AZh7GVUdGZrHQomKIq by defanor@emacs.ch
2023-09-12T15:00:14Z
0 likes, 0 repeats
@louis @galdor Did they send it to you just once? That sounds like the kind of data that needs to be updated regularly.FWIW, I do not have much experience with ASP.NET and MS SQL Server, but they do not seem that slow on their own: I guess poorly written code, a poorly designed database schema, or simply lacking optimization is more likely to cause such lags.
(DIR) Post #AZh7yqTyabk1Gqc7RA by louis@emacs.ch
2023-09-12T15:08:16Z
0 likes, 0 repeats
@defanor @galdor No, the intention is that we fetch the prices JSON in a daily basis. Even that request takes several minutes :-). However, it is a background job so user experience doesn't suffer.The issue is not the technology itself, but often when companies use such (M$) technology, they lack a deeper understanding of software design, too. They probably use a ORM or something and suffer from a multiplication of queries that are sent between their webservice and database. Yesterday I talked to a friend. He told me they run a (very expensive) Oracle and to migrate their MS Access (!) database for "remote multi-user" access. Now, they experience latency and consider to buy even more Oracle licenses to clone the database to several locations in the world.I told him, "please just give me 10% if the money and I build you something fast in Go and Postgres". But I doubt that he will be able to convince his IT department for such a move.
(DIR) Post #AZhAHAbWiQqanY0kHg by defanor@emacs.ch
2023-09-12T15:34:01Z
0 likes, 0 repeats
@louis @galdor I see. I tend to use technologies used by a project as such a heuristic to estimate what to expect there, too, but also trying to do so less: those are stereotypes, and it easily leads to prejudice. Though with some technologies it is particularly hard to avoid it, and perhaps with some it is justified, or at least there is a wide consensus (although even that may be tricky to distinguish from fashion).The Oracle story is sad, and apparently quite common.
(DIR) Post #AZhJENHC2n7uooF4CW by EMacAdie@emacs.ch
2023-09-12T17:14:21Z
0 likes, 0 repeats
@galdor A lot of TDD purists/Uncle Bob fans do not like tests that touch a DB. I don't get it either.