Live data from Hacker News

A terrible schema from a clueless programmer

rachelbythebay.com

41–50 of 493 posts

Re: A terrible schema from a clueless programmer

#41
post #8

Sorry, no. The original schema was correct, and the new one is a mistake. The reason is that the new schema adds a great deal of needless complexity, requires the overhead of foreign keys, and makes it a hassle to change things later. It's better to stick the the original design and add a unique index with key prefix compression , which all major databases do these days. This means that the leading values gets compre…

[deleted]

Re: A terrible schema from a clueless programmer

#43

Earlier quoted context omitted.

Why? She's clearly not a clueless newbie now.

I think the OP was sarcastically implying that she still is.

Such remarks generally backfire onto the author, as indeed in this case.

Re: A terrible schema from a clueless programmer

#44
Assuming this needs to be optimized for massive scale, just hash the values to a single indexed field.

And use something other than an RDBMS. Put the hash in Redis and expire the key; your code simply does an existence check for the hash. You could probably handle gmail with a big enough cluster.

That super-normalized schema looks terrible.

Re: A terrible schema from a clueless programmer

#45

Earlier quoted context omitted.

To a degree, this is true though. An engineer's salary is a huge expense for a startup, it's straight up cheaper to spend more on cloud and have the engineer work on the product itself. Once you're bigger, you can optimize, of course.

Deleted

If this is a case from real life that you have seen, you should definitely elaborate more on it. Otherwise, you are creating an extreme example that has no significance in the discussion, as I could create similarly ridiculous examples for the other side.

There are always costs and benefits to decisions. It seems that are you only looking at the costs and none of the benefits?

Re: A terrible schema from a clueless programmer

#46
post #8

Sorry, no. The original schema was correct, and the new one is a mistake. The reason is that the new schema adds a great deal of needless complexity, requires the overhead of foreign keys, and makes it a hassle to change things later. It's better to stick the the original design and add a unique index with key prefix compression , which all major databases do these days. This means that the leading values gets compre…

She doesn’t mention the write characteristics of the system but she implies that it was pretty write heavy. In that case it’s not obvious to me that putting a key prefix index on every column is the correct thing to do, because that will get toilsome very quick in high write loads. Given that she herself wrote the before and after systems 20 years ago and that the story was more about everyone having dumb mistakes wh…

It's not an index on every column. It's a single index across all columns.

Re: A terrible schema from a clueless programmer

#48
I'd really love to be snarky here but I'll try to be polite: all those comments about the example situation are missing the whole point of the post. And it really worries me that there is a good chunk of the tech workers that just ignores the real meaning of something and just nitpick about stupid implementation details. The post is about managing rookie errors, being empathetic and also warn the ageism that pervades the sector. TBH about this last point IDK the situation nowadays in Silicon Valley, but in Europe my limited experience is that ageism is not that bad; kt's actually difficult to find seasoned developers.

Edit: typos

Re: A terrible schema from a clueless programmer

#49
I think the 'terrible schema' thing is a secondary issue. The important take away for me was this:

> Considering that we as an industry tend to chase off anyone who makes it to the age of 35, is it any surprise that we have a giant flock of people roaming around trying anything that'll work?

Re: A terrible schema from a clueless programmer

#50

Earlier quoted context omitted.

Deleted

If this is a case from real life that you have seen, you should definitely elaborate more on it. Otherwise, you are creating an extreme example that has no significance in the discussion, as I could create similarly ridiculous examples for the other side. There are always costs and benefits to decisions. It seems that are you only looking at the costs and none of the benefits?

Deleted
Post reply on HN