Hacker News Reader

I guess this is an interesting question, but it seems incredibly contrary to the whole point of SQL. Two tables should never be the same, if they were, why would you have two tables. I can understand why one might want to check if two datasets were the same, which is easy to do with sort and diff, but two tables? They shouldn’t even have the same fields.

View on HN

It could be the case that the two tables represent two independent instantiations of a single or very similar concept. One might be a list of chefs and their DOBs, and another a list of robots and their manufacture date, and for whatever reason you want to see if both of them are identical. There's no reason to unify both into a single table if your data model doesn't presuppose any correlation between chefs and robots, but someone might want to see if all their chefs are robots and if all their robots work as chefs. Obviously it's a contrived example, but my point is that there exist cases where having two tables with the same columns makes sense, if they store unrelated data. That the data is unrelated doesn't mean that the tables cannot contain identical data, it just means that they don't necessarily contain identical data.

Migrating data or related processes and running a couple of things in parallel to make sure nothing was in translation… some sort of data replication hacking maybe.

Sometimes you want them to be equal, sometimes you want to know they aren’t… but it’s not out of the ordinary at all to want to check

I don’t think this article is expressing any opinions on normalization

Reply on news.ycombinator.com