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…
A terrible schema from a clueless programmer
41–50 of 493 posts
Re: A terrible schema from a clueless programmer
#42Re: A terrible schema from a clueless programmer
#43Re: A terrible schema from a clueless programmer
#44And 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
#45Earlier 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
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
#46Sorry, 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…
Re: A terrible schema from a clueless programmer
#47Re: A terrible schema from a clueless programmer
#48Edit: typos
Re: A terrible schema from a clueless programmer
#49> 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
#50Earlier 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?