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

91–100 of 464 posts

Re: Things I wished more developers knew about databases

#91

Post by yjftsjthsd-h »

lowercased wrote: post #87
yjftsjthsd-h wrote: post #78

Earlier quoted context omitted.

That sounds like bad tooling. Why not have every project use https://editorconfig.org/ and then have your IDE auto-format? It shouldn't be popping up and making you fix it, it should fix it for you.

So there are tools that autoformat as you type? let longVariableName = "hello " + this.name; magically becomes const longVariableName = `hello ${this.name}`; without visually flagging it, just autocorrects as I type? And... I can just quickly swap settings for different clients? Because one has eslint block any PRs that don't have "prefer template" rules followed but another client doesn't like that style, and don't…

I don't think that counts as a formatting issue. Yes, if your clients have hard rules about different coding styles at that level then it's not a technology problem (nor is it likely solvable with technology). I assumed we were talking about formatting issues like tabs-vs-spaces, in which case yes every single project could be different but auto-fixed.

Re: Things I wished more developers knew about databases

#92

Post by frosted-flakes »

treis wrote: post #58
gwbas1c wrote: 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…

>This kind of "magic" isn't always clear when programmers are mostly used to working with data structures and procedural code. My problem is that it is like some sort of black magic to me. If I write a complex query I have no idea if what is spit back to me is actually what I want. The only way is seeding lots of records and then manually checking that each filter and calculation is doing what I want. In code complex…

Yes, SQL's biggest fault is that it's not very composable. Complex queries end up being long and repetitive, and the order of the parts of a query is totally unintuitive (it should go something like: FROM, GROUP BY, SELECT, ORDER BY rather than SELECT, FROM, GROUP BY, ORDER BY, which makes autocompletion hard).

Re: Things I wished more developers knew about databases

#93

Post by aeyes »

hobs wrote: post #17
throwaway13337 wrote: post #14

Earlier quoted context omitted.

All of those things are unproductive until after your project is successful which is usually not a guarantee when building the software. You're not gonna need it.

Observeability, reliability, scalability - really easy to bolt on once you are successful. There's a middle ground, and a DBA turned SRE turned Architect is probably ok with compromises, those are all roles where "it depends" is a bylaw.

How is scalability easy to bolt on? Most companies end up rewriting their entires stack, multiple times.

Re: Things I wished more developers knew about databases

#94

Post by alexbanks »

taffer wrote: post #89
crazygringo wrote: post #52

Earlier quoted context omitted.

SQL is very much like CSS to me. It's declarative, the primitives seem entirely non-intuitive, it often takes a lot of fiddling to get what you want, the behind-the-scenes execution is mostly a black box, and while it's supposed to work the same on different implementations (of browsers/databases), there are tons of little gotcha quirks. All in all, they're both entirely different skill sets from traditional programm…

When you look at SQL from a logical/set-based perspective, it is by no means unintuitive. Basically, all you do is join all the tables you need and then filter out everything you don't need and maybe do an aggregation here and there.

And with CSS, basically all you do is tell the browser how things look.

Re: Things I wished more developers knew about databases

#95

Post by Buttons840 »

I learned SQL working on a "database as a product". The database was filled with medical ontologies. It was a perfect environment for learning. We were always looking for obscure things in that database, and rarely changed data, just selects for days. In the end I once wrote a query spanning about 100 lines that used common table expressions and found it quite maintainable.

Where can an SQL beginner find such a database to experiment with? I was fortunate because my job provided me this database to experiment with, but what about those who are not so fortunate?

Re: Things I wished more developers knew about databases

#96

Post by strbean »

a_c wrote: post #20

Learn about modelling. Database is more than just storing data. Drink less koolaid of NoSQL, any NoSQL. It is trading initial result with future development time. SQL has been battlefield tested. No amount of "convenience" is more convenient than learning the fundamentals.

I'm disappointed that there isn't more criticism of the SQL language. The whole NoSQL buzz got me excited, then turned out to actually mean NoRelational.

It is wild that we are still using a language that looks and feels like COBOL, and any criticism is met with drive-by disapproval (downvotes and no comments) or an argument about why relational databases are important.

SQL is a deeply flawed language by standards that are pretty much universal today - we on HN discuss them daily on posts about new programming languages. For example, one of the top level comments here:

> In SQL it boils down to the fundamental syntactical requirement to put the SELECT clause before the FROM clause. So I have to build up my statement in this weird spiral pattern where I change something deeper in before I know what I can SELECT in the first place.

If this were the case for a new language post on HN, the author would get run out of town for this reason alone. And yet, the person who wrote that comment feels the need to hedge by saying they are "an SQL hater in remediation".

Relational data does require a mode of thinking that many programmers are not practiced with. Wouldn't it help to have a language for working with it that isn't outright terrible?

Re: Things I wished more developers knew about databases

#97

Post by karatestomp »

TremendousJudge wrote: post #82
brightball wrote: post #56

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…

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

But going too far the other way is how you end up with performance 100-1000x worse than it should be. Which is an actual thing that happens quite often in the wild. Also often ends up heavily dependent on some ORM or framework, making rewrites or multi-client DB access dangerous and painful.

Re: Things I wished more developers knew about databases

#98

Post by taffer »

pbowyer wrote: post #69
sk5t wrote: post #55

Earlier quoted context omitted.

A more functional mindset can definitely help here. Think of your "sales per day" model in terms of starting with a sequence of days--startingDay up to startingDay + n--as the input to a function that maps to an aggregate of that day's activity. Aggregate functions in SQL are IMHO quite awesome once you develop a comfort level to stop worrying about them per se. I wouldn't like to try to get Excel to tell me--or writ…

I find thinking about analytic queries like these as map/filter/reduce easier than thinking in terms of the SQL!

SQL and functional programming constructs are actually quite similar:

SELECT -> map

FROM -> stream

JOIN -> flatMap

WHERE -> filter

GROUP BY -> collect

ORDER BY -> sorted

https://blog.jooq.org/2015/08/13/common-sql-clauses-and-thei...

Re: Things I wished more developers knew about databases

#99

Post by kyllo »

wenc wrote: 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…

TFA isn't even about SQL the language at all though, it's about the scalability and reliability characteristics of databases, especially in a distributed environment.

Re: Things I wished more developers knew about databases

#100

Post by 411111111111111 »

taffer wrote: post #89
crazygringo wrote: post #52

Earlier quoted context omitted.

SQL is very much like CSS to me. It's declarative, the primitives seem entirely non-intuitive, it often takes a lot of fiddling to get what you want, the behind-the-scenes execution is mostly a black box, and while it's supposed to work the same on different implementations (of browsers/databases), there are tons of little gotcha quirks. All in all, they're both entirely different skill sets from traditional programm…

When you look at SQL from a logical/set-based perspective, it is by no means unintuitive. Basically, all you do is join all the tables you need and then filter out everything you don't need and maybe do an aggregation here and there.

SQL can do a lot more though.

Triggers, functions, procedures, access control.....

Post reply on HN