Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I wished more developers knew about databases

medium.com

Post reply on HN
Print view View original

391–400 of 464 posts

Re: Things I wished more developers knew about databases

#391

Post by devonkim »

collyw wrote: post #361
listenallyall wrote: post #344

Earlier quoted context omitted.

>> That ended up fixing the problem Interesting take, since you're still stuck with "simple reports" that take hours to run. What about writing more efficient queries, adding indexes, normalizing the DB... ?

It amazes me the complexity of solutions these days, when 20 years ago almost everything ran in relational databases and query tuning was usually the solution to performance problems.

Because we got rid of DBAs in favor of “big data” developers that never learned much about SQL in the first place.

Re: Things I wished more developers knew about databases

#392

Post by seanc »

hermitdev wrote: post #256
harikb wrote: post #200

Earlier quoted context omitted.

Go sql/database uses its own connection pool. But still that shouldn't create any problems. I have seen the reverse where apps that assumed temporary tables stick around from statement to statement without an explict `txn` (which regular postgres connections don't need) clearly failed. But I have not seen the issue you talk about. My wild guess would be that the Go code never closed the result/rows which caused eithe…

At a previous employer, I was forced to use a certain 3rd party ODBC library. Under certain circumstances, it would just do `exit(1)`, with nothing even to stderr. Very frustrating and annoying to debug/fix. Had I physically known the developer responsible for that behavior, I'd probably have faced murder charges and plead temporary insanity.

"Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

I usually maintain my own code, so the as-if is true. "

http://wiki.c2.com/?CodeForTheMaintainer

Re: Things I wished more developers knew about databases

#393

Post by eeZah7Ux »

0xy wrote: post #321
eeZah7Ux wrote: post #215

Earlier quoted context omitted.

> The most senior developer (24yo or so) I see the problem there.

Shameless age discrimination. Very smart people exist at all ages. I've seen 21yo junior grad developers outperform 45yo 'senior' developers.

Do not accuse people without evidence! I'm all against age discrimination.

..and when you see a company where the age cluster around a very small area you can tell age discrimination is happening. Which might very well be the case of the parent post.

Re: Things I wished more developers knew about databases

#394

Post by Aeolun »

shaklee3 wrote: post #328
Aeolun wrote: post #327

Earlier quoted context omitted.

Most people don’t magically grow wiser with time. They need to be in an environment where they can grow, otherwise they’ll emerge just as stupid as before.

The counterpoint is you need time to grow wise, and there's no way to get wise without many years of experience.

That’s also true. I guess that the relative percentage of people you’d call wise increases with age.

Re: Things I wished more developers knew about databases

#395

Post by PappaPatat »

THE thing I wished more developers knew about databases: they are badass when it comes to data manipulation.

Stop sucking all data and manipulate it in your language of choice. Tell you DBA what you want done and let her do it for you.

Really, DB's may look like they are the special needs kid in the chain, but they're magnificent powerhouses when it comes to 90% of what you are trying to do to data.

Re: Things I wished more developers knew about databases

#396

Post by ivanche »

lowercased wrote: post #265
PunksATawnyFill wrote: post #250

Earlier quoted context omitted.

The solution isn't to force style on programmers within the language. It's to fix the shitty diff tools that flag whitespace changes as significant.

when people care whether you have if(foo) { or if (foo) { or if (foo) { you end up in pointless arguments. I don't care about this sort of formatting very much (I have my own default style developed over years), but I do care when other people care about it, often to the exclusion of other factors. "but we need these tools so that we don't argue about how to format code". Well... you could... just not argue about it…

I think it's not at all pointless to have consistent code style throughout codebase. I agree, though, it's pointless to argue (thus losing time) about "correct" style. It should be enforced on project or company level, no discussions between developers there.

Re: Things I wished more developers knew about databases

#397

Post by jtdev »

vsareto wrote: post #12
falcolas wrote: post #7

(The 80/20 rule applies below, some developers do care) Developers... just don't care. They want to spin up an ORM, point it at a URI, and forget about it. I've fought this for over a decade now as a DBA, SRE, DevOps, and architect. Most of the developers don't want to deal with anything infrastructure-wise; they want to spend all the time they can just focusing on the problem they're writing software to solve. Obser…

Many interests are pulling developers' attention in several different areas all the time. Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things All of these like to say "if only the developer could do $MY_AREA better, they'd be better developers and we'd have better software". Each of them wants to pile on…

> Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things

Hammers, nails, tape measures, saws, levels, reading blueprints, adhesives... If you want to be a professional, you need to learn the tools of your trade. Being able to work directly with a SQL database is a foundational capability in the software development trade. ORMs are a mental crutch that are overused to the detriment of many systems.

Re: Things I wished more developers knew about databases

#398

Post by horsawlarway »

jtdev wrote: post #397
vsareto wrote: post #12

Earlier quoted context omitted.

Many interests are pulling developers' attention in several different areas all the time. Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things All of these like to say "if only the developer could do $MY_AREA better, they'd be better developers and we'd have better software". Each of them wants to pile on…

> Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things Hammers, nails, tape measures, saws, levels, reading blueprints, adhesives... If you want to be a professional, you need to learn the tools of your trade. Being able to work directly with a SQL database is a foundational capability in the software dev…

Speed squares are a mental crutch that are overused to the detriment of many structures...

Look, I actually agree with you about ORMs, but come on, this is a pretty bad take on the problem.

The issue is rarely the tool itself, it's the changing requirements around how it's used.

You can have the best hammer swing in the world, and maybe you sling the best tape ever. But if the building codes are revamped in non-trivial ways every 6 months, you're still going to want someone spending dedicated time understanding that. If your job is to assemble the stairs, you focus on that instead of wasting time asking why this blueprint happens to place the stairs at a slightly different angle, or why some places demand kiln dried timber vs simple construction grade.

Your area of expertise is NOT the building code, it's integrating the stairs into the rest of the structure and actually having people walk up them.

Re: Things I wished more developers knew about databases

#399

Post by hobs »

wenc wrote: post #198
TremendousJudge wrote: post #82

Earlier quoted context omitted.

> The application language was a pass through later between the client and the database. This style of doing things resulted in spaghetti style unmanageable databases, filled with an unknowable number of triggers and procedures, all written in PL/SQL (which is much, much worse than either Java or PHP). The reason why ORMs started to become popular is that you can write your application without filling your DB with ar…

There's a middle way which is very powerful: SQL views (just SQL queries; no triggers or procedures) Here's a powerful mindset trick: think of SQL views as an sort of a REST API , but whose access language is SQL and not HTTP, and that returns data in a table rather than JSON (hierarchical). I once tried to build a REST API to a database, and someone told me I already had a battle-tested and highly performant API tha…

Right, and this is normal except that people take it too far, I love to find 10(!) depth nested views hiding table valued functions and scalar functions everywhere - you cant reason about the rat's nest created.

If you want to make simple views that expose useful nouns I am down with it, but I have seen it taken too far too many times.

Re: Things I wished more developers knew about databases

#400

Post by hobs »

throwaway_pdp09 wrote: post #190
corey_moncure wrote: post #42

Earlier quoted context omitted.

I'm an SQL hater in remediation. In a given week I might work with all of the following: SQL, C#, Python, JS (Kendo, Vue, React), XSL, bash, and more. I'm a quick learner and I pick things up fast, always have, I've got a deadline and I don't have the time or capacity to fully internalize the minutiae of all the technologies I have to work with. In other words I depend on the tools to show me the options at my dispos…

> In SQL it boils down to the fundamental syntactical requirement to put the SELECT clause before the FROM clause No offence but if you are at the level of struggling with the syntax then you should not be using SQL until you have more experience. There have been plenty of well-founded critiques of the crappy syntax of SQL, but it's not ultimately that hard. There are worse things you'll have to cope with such as the…

I would not throw someone at CTEs who is using SQL Server - just use temp tables for each component you would be CTE-ing, CTE's dont get any benefit from re-use except from a code perspective, whereas composing your sets into temp tables will often get you exactly what you want, individual sets that you can re-use throughout your code.
Post reply on HN