undefined | Better HN

0 pointsyxhuvud13y ago0 comments

The problem with your argument is that all problem will look like it will have polymorphic and ambigous data until you have mapped it out properly. What the post you replied to was basically an advice for new projects and developers to fully map out the problem and see where things are going.

It is a lot easier to start strict and organized and back down to less strictness with looser rules where you need it, than to do the opposite.

0 comments

3 comments · 1 top-level

stickfigure13y ago· 2 in thread

Perhaps for "new developers". If the question is "as a neophyte developer, which should I learn first, Postgres or MongoDB?" then I would tend to lean towards SQL as well. But that isn't the proposal.

The problem is the old cliche that if all you have is a hammer, everything looks like a nail. "Just start with a hammer" is bad advice because with enough effort and willingness to cause collateral damage, you can almost always get a screw in with a hammer. If you've never seen a screwdriver, you're doomed to posting HN stories about "how I spent the last three weeks rebuilding my application architecture to deal with the fact that hammered-in screws tend to fall out a lot."

flatline313y ago

You failed to address the parents point entirely: it's a lot easier to start strict and loosen restrictions later, than it is to start loose and add restrictions.

stickfigure13y ago

I'm not sure what this has to do with SQL vs NoSQL. There are myriad differences between storage systems which have little to do with referential integrity constraints or data validation.

Polymorphic structures are a PITA to model in relational tables, but they fit very well in schemaless, document-oriented NoSQL systems. This has nothing to do with data validation.

Rapidly changing schemas are a PITA in RDBMSes, especially with a large cluster of servers. It's usually very easy to alter schemas on-the-fly with NoSQL systems. This has nothing to do with data validation.

On a related point, the database is a crappy place to put data validation anyways. It can only do the most primitive forms of validation (is this an integer? is the FK reference valid?). Application level-validation gives you the full power of a modern programming language and all the data you could possibly want to fetch. Yeah, "senior discount" is a float... but it should only be given to people over age 65.

The fact that the OP managed to insert "111" into a column instead of 111 means he is using crappy tools. My datastore api guarantees that integer fields in my (statically typed) classes are written as integers. I never have this problem, nor have I ever taken down my GAE (NoSQL) applications for maintenance.

1 more reply

j / k navigate · click thread line to collapse