Hacker News Reader

Comment by distantsounds | Hacker News Reader

Really, you can't spend the 10 minutes designing a table structure in a SQL database? And now you have to spend months re-inventing the wheel because you wanted an easy out?

This post reflects on developers being lazy, instead of doing it right the first time around. Oh no, you have to log in to the db and run a CREATE TABLE statement every few months when you need to scale. Cry some more.

And even then, 'lazy' is subjective. I don't find SQL that hard to implement. There's a library for practically every language you can think of. What's your excuse?

View on HN

Actually, I think that's a great way to think about it: NoSQL is the "dynamic typing" of the database world.

Put another way, it's like "what? you couldn't spend 10 minutes declaring types everywhere?" - yeah, it's less robust, yet dynamically typed languages remain popular.

My excuse: When I'm just past the mock stage, and still playing with what UI functionality should be, sometimes I just want to get some JSON persisted. I'm changing the shape of the data a lot, discovering the schema as I build. The persistence is frankly a technical nuisance I wish I didn't have to think about.

Sometimes, the result is "good enough" and I don't need to go through the ceremony of glueing in an ORM.

I read this article and was just like "ya. types are important" and reflected on how I used to love Ruby, but now swear against it for serious projects. Glad to see I'm not the only one who made the analogy in their heads.

Right now though, I have to write a script to pull some crap out of an Excel file and into my database. I use Scala with the Play framework, but what a nightmare getting typed information out of an Excel sheet is. No thanks, I'll just pull it out magically with Ruby and construct the JSON requests to my real server to create the data. It's a smart business decision and I would defend it all day. I'm sure there's corollaries for "dynamic databases" such as MongoDB.

To be clear though, I'm with the grandparent. I really think decisions for MongoDB are made out of a combination of laziness and eagerness most of the time. I mean honestly, if your data is going to be relatable, why would you employ a scheme that forces you to make those relationships manually? So you go to a relational databases which ironically lacks relationships, but hey there's plenty of support and libraries that will do it for you. But really if you had to ask me my personal opinion? Graph databases where relationships are FIRST CLASS CITIZENS are typically the best for serious projects containing lots of relationships.

Your given excuse makes you sound more like a naive amateur instead of a pragmatic architect

Just in case GP cares: To me it did not sound like this at all. I think making prototypes and starting to build the thing is the key to getting to a good architecture.

The difference there is that you enter types for thousands of lines of code. OTOH a schema is changed relatively infrequently. Maybe a few times a day during really experimental stuff.

I guarantee you're not designing your databases correctly if they only take you 10 minutes and only a CREATE TABLE statement every few months.

You don't even need to design the schema, just add the bits you need as you go (updating the schema takes about 20 seconds with rails for instance).

I think you're understating the cost of updating the structure of an in-use database.

I'm not even sure if you're referring to an rdbms or Mongo, which is kind of the other side there. I _think_ you're referring to an rdbms. But I also think people seriously understate the cost of changing the way your data is stored in a large in-use MongoDb too.

Mostly because an RDBMS will ask you to explain, explicitly, in complete detail, how you propose to consolidate the entire schema and existing data with the new changes without introducing paradoxes or inconsistencies.

Mongo won't. It will take you at your word. Even if that word is wrong.

Definitely not about spending 10 minutes on SQL Schema. It is all about maintenance. MongoDB is right use case, if you know what it will be there in Table.

In some cases you don't even have to log into anything, just type one line to create migration and another line to run it.

Reply on news.ycombinator.com