Hacker News Reader

Comment by timaelliott | Hacker News Reader

I disagree. By restricting the number of rows I think you're just going to end up with folks creating sloppy schemas specifically to avoid going over the limit.

  post.categories (varchar) = "1,51,78,84,100"

and other wonderful non-normalized approaches.

View on HN

Hm. If you must do that, remember Postgres is guilt-free-SQL, so don't use a varchar, use the array type.

http://www.postgresql.org/docs/9.1/static/arrays.html

or hstore https://postgres.heroku.com/blog/past/2012/3/14/introducing_...

I like that you guys pointed out more efficient ways to do stupid things :)

Well, if the time it takes you to contort your application to work around our row limits is worth less to you than $9/mo, you're probably in need of both technical and financial advice.

I don't disagree nor do I use heroku, it's moot for myself.

I was just commenting how row-limitations were a very NoSQL way of enforcing data limits and inappropriate for an RDBMS.

Oh, you don't need to use Heroku to take advantage of Heroku Postgres -- it's available as a standalone service.

People willing to go to extremes to save a few bucks are probably not hosting on Heroku to begin with. This doesn't seem like a scenario worth worrying about.

10 million rows though is a high enough limit to make that unnecessary.

Of course any limit can be engineered against. When I was in college, the deli used to have a deal where you could get a baked potato with whatever toppings you wanted for $1.50 or something. one of the topings was chilli. So I would fill the container up with chilli so it was more like potato chilli..... After a while they started charging by weight because apparently this was a popular approach to this esp. for college kids who would rather cut food expenses and spend money on other things.

Make a horrible schema just to avoid ten dollars a month? Surely the time of most developers is worth more than that.

Give a person an limit and he will try to overcome it no matter how silly it is.

I find over-normalizing databases to be just as much of a problem. "Perfectly normalized" databases create extremely nasty join statements which can create just as much havoc as poorly normalized databases, especially once an ORM is thrown into the mix, which most will be using.

Reply on news.ycombinator.com