Live data from Hacker News

Things I wished more developers knew about databases

medium.com

461–464 of 464 posts

Re: Things I wished more developers knew about databases

#461
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 feels to me like bash or regular expressions. You can do amazing things if you do it full time. But if you do it only a few times per month or year you quickly forget all the subtleties and it gets hard to understand even the stuff you wrote half a year ago. I guess in the end things have become so complex that as a dev you can’t be good at everything. I often wish there were dedicated database guys but if you ha…

I tend to disagree, since I find SQL orders of magnitude more intuitive than regular expressions, having no problem picking it up once every couple of months without requiring to fallback on books or cheat sheets for implementing the majority of queries. Sure, every now and then we have to optimize a query or implement a complex data extraction pattern forcing us to study how to do it, but for me this is unusual.

The key aspect of SQL that makes it easy for me is readability. Once you know the basics you can understand what a query is doing just by looking at it. Regular expressions notation on the other hand are really though to read, and indeed I keep always forgetting its syntax.

Re: Things I wished more developers knew about databases

#462
post #47

Earlier quoted context omitted.

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 sak…

(I could be wrong,) but I thought one of the points of stored procedures was that the query plan is precompiled?

Re: Things I wished more developers knew about databases

#463

Earlier quoted context omitted.

I firmly believe that every developer should spend 2-3 weeks early in their career working with nothing but SQL. It will pay huge dividends for the rest of it. IMO a lot of the issue is that developers for many years using Java or PHP, were using SQL to handle everything. The application language was a pass through later between the client and the database. Your goal was to accomplish as much as possible in a single…

> I firmly believe that every developer should spend 2-3 weeks early in their career working with nothing but SQL. It will pay huge dividends for the rest of it. That pretty much describes my career, except it was more than 2-3 weeks. I agree there is value in being familiar with the ins and outs of SQL, but... > As soon as people get a basic comfort level with SQL, it become almost automatic. I don't know about that…

>Where is the declarative query language equivalent of Rust, Haskell, etc.?

Maybe Cypher from Neo4j?

Re: Things I wished more developers knew about databases

#464
post #451

Earlier quoted context omitted.

Agree with this. There's the whole DevOps nowdays as well, which basically just shifts what used to be an entirely separate, full-time, role onto the developer. Adding DBA to that sounds like it would benefit noone, except perhaps business owners looking for short-term savings at the expense of productivity, ala open-office floor plans.

In most places I have worked, knowing the database well enough to manage it and at very least write stored procedures has always been expected from developers writing database related code. I have been doing this for a little more than 30 years now, so it isn't "nowadays" thing.

Sure, knowing your database well enough to "manage it" in terms of indexes, bloat, writing procedures, that's a developer responsibility.

What is "new", is developers having to manage the DB backups, k8s clusters, Docker images, Terraform, load balancers, CI/CD, proxies etc.

This used to be a role for a whole another role. Some places do have an "Ops" role, but most tasks are still expected off the developer, with Ops at best providing a helping hand, rather than taking over a task completely.

Post reply on HN