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

241–250 of 464 posts

Re: Things I wished more developers knew about databases

#241

Post by AsyncAwait »

vsareto wrote: post #227
debaserab2 wrote: post #214

Earlier quoted context omitted.

I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data. There's a lot of devs that think database design is the same as starting a new ORM class and generating a migration file. > Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), lan…

> I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data. There's usually not a relationship that goes the other way though, for example, developers don't tell DBAs to pick up code so they can write the models in our language in addition to the underlying SQL. This highlights a trend of increasing responsibilities push…

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.

Re: Things I wished more developers knew about databases

#242

Post by cgh »

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…

Agreed, and a good example of this is implementing search. You can define a view on top of your searchable entities that includes the urls to the entities, as well as searchable metadata (entity descriptions or whatever). So when you add new searchable items, you just update the view to include them and the code to select from the view doesn't change.

Re: Things I wished more developers knew about databases

#243

Post by cat199 »

crazygringo wrote: post #52
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…

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…

> it often takes a lot of fiddling to get what you want

and yet, for any nontrivial operations, opting for a few simple K:V stores instead means one basically ends up implementing an unrolled SQL engine processing loop to do the application-specific select statements you would otherwise need.

there's a reason SQLite took over from dbm files ...

Re: Things I wished more developers knew about databases

#244

Post by strbean »

a_c wrote: post #147
strbean wrote: post #96

Earlier quoted context omitted.

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

SQL stood the test of time. SQL is widely adopted. Once you get the hang of it, it can be applied on a wide range of RDBMS. I would argue that countless productivity has been lost to learning yet another query language for yet another NoSQL db. Mongo has its own query language. Cassandra has its own. Neo4j has its own. What not. Guess what, few engineers need these to solve their actual problem. Be it building an app…

> SQL stood the test of time. SQL is widely adopted.

I'm highly dubious of "it is widely used so there" arguments. I think in the case of SQL, the fact that ORMs and SQL generators are ubiquitous are evidence that a huge proportion of engineers would rather not write it, and part of why it is still widely used (most of the time, most people can avoid actually touching it).

> I would argue that countless productivity has been lost to learning yet another query language for yet another NoSQL db. Mongo has its own query language. Cassandra has its own. Neo4j has its own. What not. Guess what, few engineers need these to solve their actual problem.

This is exactly one of the points I addressed in my comment... none of those are even relational databases. And this is where the discussion ends up every time someone says SQL sucks.

> Is english the best language? No, not even close. Should one learn it? Probably.

The vast majority of the time, when you are using English, you have no control over the receiving end. The vast majority of time, when you are using SQL, you / your org grabbed an SQL RDBMS to use.

Furthermore, I don't see why a modern, reasonable query language couldn't transpile to SQL easily when necessary, making all path-dependency / adoption arguments void.

Re: Things I wished more developers knew about databases

#245

Post by acdha »

fools wrote: post #236
acdha wrote: post #172

Earlier quoted context omitted.

> 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. My reaction to that is that it's similar in a different way: everyone needs to use it but many developers don't…

If I write a C program, especially with the appropriate compiler warnings enabled, or some filesystem code, there is a high chance that it will work across platforms with no further coding necessary. Anecdotally, the same cannot be said for CSS or SQL. It doesn't matter much for SQL, because I always know what database I'm using, but for CSS, it's a massive pain.

That's a charming belief about C which is only true if you work on the same operating system, processor, and don't do anything complicated. If those are not true, as I've experienced many times over the years, you will learn otherwise about things like differences in floating point behaviour, memory allocation and access patterns, which filesystem and/or locking semantics, etc.

In other words, it's about as true as it is for CSS and SQL, where that kind of simple use is also stable.

Re: Things I wished more developers knew about databases

#246

Post by fools »

acdha wrote: post #245
fools wrote: post #236

Earlier quoted context omitted.

If I write a C program, especially with the appropriate compiler warnings enabled, or some filesystem code, there is a high chance that it will work across platforms with no further coding necessary. Anecdotally, the same cannot be said for CSS or SQL. It doesn't matter much for SQL, because I always know what database I'm using, but for CSS, it's a massive pain.

That's a charming belief about C which is only true if you work on the same operating system, processor, and don't do anything complicated. If those are not true, as I've experienced many times over the years, you will learn otherwise about things like differences in floating point behaviour, memory allocation and access patterns, which filesystem and/or locking semantics, etc. In other words, it's about as true as i…

Yes, I write fairly boring applications. But the point is that C is mostly cross-platform for those boring applications, whereas the the "cross-platformness" of CSS and SQL fall apart for even the simplest of tasks.

Re: Things I wished more developers knew about databases

#247

Post by debaserab2 »

vsareto wrote: post #227
debaserab2 wrote: post #214

Earlier quoted context omitted.

I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data. There's a lot of devs that think database design is the same as starting a new ORM class and generating a migration file. > Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), lan…

> I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data. There's usually not a relationship that goes the other way though, for example, developers don't tell DBAs to pick up code so they can write the models in our language in addition to the underlying SQL. This highlights a trend of increasing responsibilities push…

> There's usually not a relationship that goes the other way though, for example, developers don't tell DBAs to pick up code so they can write the models in our language in addition to the underlying SQL. This highlights a trend of increasing responsibilities pushed onto the developer.

Yes, because as a developer you're the one who has the responsibility of implementing the business requirements of the app. There's no trend here; this is the way it's always been. The buck stops with development for a lot of things. The developer is in a unique position to respond to many incidents because they have an intimate understanding of how the business requirements wed with the technology in ways someone like a DBA does not.

DBA's have plenty of responsibilities of their own, such as handling a 3AM alarm that goes off when some part on the application starts hammering the DB from some poorly designed N+1 query problem in the codebase. Often times when the DBA tries to teach the developer it's because he's sick of getting those 3AM wake-up calls.

> But in some cases it's specialists designating what an expert developer should know. It's giving away control in some respects. This turns into new job requirements and a higher barrier for entry. The growth will need to stop at some point.

That's a strange mindset to have. Different jobs have different technologies, and as a developer you learn how to work with them. The specialists aren't designating anything, the job you're responsible for is.

Re: Things I wished more developers knew about databases

#248

Post by hobs »

Macha wrote: post #233
hobs wrote: post #33

Earlier quoted context omitted.

There's a simple fix - Don't you ever expose primary keys to the users. Ever. Seriously, ever. A primary key is not an order id, it isnt a person identifier, it isnt a paycheck - its a thing the database should be using behind the scenes. All of the things I just mentioned change - besides the primary key. You'll never have this problem if you separate your business logic from your keys.

This is why I'm skeptical of the suggestion to prefer a natural primary key like a username. It works fine... until they day the business asks for changeable usernames because BigClient is now LargeClient and can't stand anything to still have their old brand identity.

Even in the natural key's playground (in my mind) of data warehousing, you still have to manage changing dimensions, and the inevitable reality that your fact table was actually another dimension table all long.

Re: Things I wished more developers knew about databases

#249

Post by acdha »

fools wrote: post #246
acdha wrote: post #245

Earlier quoted context omitted.

That's a charming belief about C which is only true if you work on the same operating system, processor, and don't do anything complicated. If those are not true, as I've experienced many times over the years, you will learn otherwise about things like differences in floating point behaviour, memory allocation and access patterns, which filesystem and/or locking semantics, etc. In other words, it's about as true as i…

Yes, I write fairly boring applications. But the point is that C is mostly cross-platform for those boring applications, whereas the the "cross-platformness" of CSS and SQL fall apart for even the simplest of tasks.

Again, I think you're viewing this through the lens of relative experience. I have seen tons of C code which required substantial fixes to work portably (bonus points when this was exploitable) and I have plenty of CSS and SQL which hasn't had to be touched in years.

Re: Things I wished more developers knew about databases

#250

Post by PunksATawnyFill »

bdamm wrote: post #34
mgkimsal wrote: post #25

Earlier quoted context omitted.

> 2 years working on a non-trivial backend should expose one to these problems. You can be exposed to them, but without understanding them, and experiencing both good, bad, and really bad 'solutions' to them, and understand the impact (on the business, on the code, on security, on maintainability, etc)... you just can't really get all that in 2 years. I know plenty of people who've been 'exposed' to certain type of t…

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.
Post reply on HN