Live data from Hacker News

Things I wished more developers knew about databases

medium.com

261–270 of 464 posts

Re: Things I wished more developers knew about databases

#261
post #228

Earlier quoted context omitted.

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

I've seen older developers that call themselves senior, but lack basic knowledge. I've seen younger developers, wise well beyond their years. Age simply isn't a big factor in how you judge a developer.

Just because you saw a few exception does not mean the rule does not hold in general. Or are you saying most people don't learn with time (a corollary of your theory that age is not a big factor)?

Re: Things I wished more developers knew about databases

#262
post #47
post #16

I never realized this before but many excellent developers struggle with SQL beyond simple SELECT statements. I have a colleague who is by all accounts a deeply technical person but one day he confessed to me that he didn't really grok SQL and that he'd rather work with a "real" procedural programming language to just store and retrieve data. Part of it may be due to the fact SQL isn't really a programming language b…

Part of the issue is that a complicated database can handle the same SQL query many different ways based on indexes and other configurations. This kind of "magic" isn't always clear when programmers are mostly used to working with data structures and procedural code. The other problem, IMO, is that programming languages are very poor at bridging the difference between the SQL domain and the language domain. We really…

The thing that really worries me when I'm writing SQL is the possibility that the query planner will get frisky and choose some disastrously slow join order, but only once in a while. I've run into way too many hard-to-reproduce performance issues like this.

Having the database automatically figure out how to run a query is a great feature, but most of the time I'd happily just write explicit nested loops for the sake of predictability.

Re: Things I wished more developers knew about databases

#263
post #198

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…

Not only that, but VIEWs can have INSTEAD OF triggers, which then lets you build powerful abstractions in SQL.

Re: Things I wished more developers knew about databases

#265
post #34

Earlier quoted context omitted.

I wish I could slap anyone who gives a hoot about tabs vs spaces. Fortunately modern languages like go are removing the version control problem that not caring about style and using auto-formatting IDEs produces.

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 in the first place.

Re: Things I wished more developers knew about databases

#266

One thing I've noticed that in the medium term of a software service (2-5 years) is that your software should have the ability to do double-writes to and flip reads between two different datastores. That will afford migration with as close to transparent migration with as reduced a downtime or no downtime.

wat. particularly today with logical replication this is pretty much unnecessary.

Re: Things I wished more developers knew about databases

#267
post #16

I never realized this before but many excellent developers struggle with SQL beyond simple SELECT statements. I have a colleague who is by all accounts a deeply technical person but one day he confessed to me that he didn't really grok SQL and that he'd rather work with a "real" procedural programming language to just store and retrieve data. Part of it may be due to the fact SQL isn't really a programming language b…

SQL really is a programming language though. It's just not imperative.

Re: Things I wished more developers knew about databases

#268
post #230

An odd thing that happened to me yesterday with the PostgreSQL ODBC driver (psqlODBC) v9.3.400. It wouldn't let me insert a string longer than 255 characters long into a character varying field into a local v9.4 database on windows using a recordset update. I didn't have a problem pasting it in via pgadmin. Altered the field to text and the problem went away. I've a suspicion that there is a limit on text in the tens…

That sounds like a bug in the driver. I'm pretty sure varchar on postgres is just an alias for text, which has no limit.

edit: varchar(n) will issue an error past n bytes, varchar without n is the same as text. character varying(n) is like varchar(n).

https://www.postgresql.org/docs/9.4/datatype-character.html

Re: Things I wished more developers knew about databases

#269

Earlier quoted context omitted.

jOOQ can be used in a less-type-safe way. For example, `fetchMaps` [1] does more-or-less what you describe. However, I have found it worthwhile to learn to use the more advanced features you mention. Extending type safety to queries is incredibly useful. Consider cases when developers are making code and schema changes concurrently that overlap. [1] https://www.jooq.org/javadoc/latest/org.jooq/org/jooq/Result...

SQL (at least in Postgres) is already type safe.

jOOQ can effectively extend the type system of Java to the construction of ad-hoc queries by way of code generation. jOOQ generates Java classes that correspond to the database schema, which can be used in its query building DSL.

For example, if I have a `timestamp with time zone` column in PostgreSQL, that is represented in the generated code. I will be prevented from inserting a Java `String` into that column - I will have to provide an `OffsetDateTime`. (This is how it would be in a typical configuration - it is flexible enough to do pretty much anything).

Another example, let's say I reference some column in a query in one of my feature branches. Meanwhile, somebody has dropped that column on the master branch. When I rebase my feature branch onto master, my build will fail.

Re: Things I wished more developers knew about databases

#270
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…

Not meaning to come off as trite, but I know my response will sound like I am.

But, what you described is exactly why senior devs/engineers make 2x, 3x, 4x a junior.

Seniors make more because they have that extra knowledge you're talking about that can take a decade or more to accumulate. The idiosyncrasies between different DBMS or even languages or even specific versions of languages. That knowledge doesn't come cheap. It literally takes upon years to develop.

This is partially why I think bootcamps are bullshit. I'm sorry, but there is no way to become a competent full-stack developer, especially if you're not targeting web/browser. Give me someone with 3 months of bootcamp C++, I'd be surprised if they can get a nontrivial program to link, let alone compile.

Post reply on HN