Refactoring out a boolean column I have a Pets table (cats, dogs, you name it) with over a million records.  For simplicity sake, it looks like the following:

Pets
Field   Type            Null    Key
id      int(11)         NO      PRI
name    varchar(256)    NO


For the front page on my site, I want to show off 5 random pets to display every month.

I was considering adding a new boolean column to the Pets table for identifying the 5 Pets I'll be showing each month.  But!  I'd have hundreds of thousands of records with false column values, just so that I could have 5 records with true values; which my gut was telling me, doesn't sound very normalized.

So!  I was wondering if it might make sense to refactor the selected records into a new table instead, like below.

PetDisplay
Field   Type            Null    Key
id      int(11)         NO      PRI
pet_id  int(11)         NO      MUL  &lt;&lt;&lt; Foreign key to Pets Table


That way, the new table could just track the 5 selected records, instead of having a column with hundreds of thousands of empty values.  Does that make sense?  Would this actually perform better, or would it be an unnecessary abstraction?  Are there any general database rules around making refactoring decisions like this?

Thanks y'all!
Putting the flag directly in Pets is still normalized. It might not be high-performance, though.

Pulling the five rows into a separate store will undoubedly perform better. Is it normalized? Well, there are a great many normal forms, one of which puts each non-key attribute in its own table. So yes, its normalized. If you put non-key columns in the new table then you risk update anomolies, which means that table is no longer normalized. I'd wear that cost for the simplified run-time.

What other alternatives exist? An index involving the flag column may help at the cost of extra work for all writes. A filtered index or materialised view would be better, if only MySQL supported them.