That is a very denormalized design, as you have pointed out yourself. Especially if there isn't always a 1 : 7 ratio of
Phone Numbers to
Flags. Depending on your business data, you could potentially have a vast amount of sparse data.
I'd recommend a thin, normalized structure like this:
create table Flag
pkFlag int identity(1, 1) not null primary key clustered,
FValue varchar(100) not null
create table PhoneNumber
pkPhoneNumber int identity(1, 1) not null primary key clustered,
PnValue varchar(20) not null
create table PhoneNumberFlag
fkFlag int not null foreign key references Flag(pkFlag),
fkPhoneNumber int not null foreign key references PhoneNumber(pkPhoneNumber)
This allows you to create a one-to-many relationship (or possibly a many-to-many relationship, I can't say for sure as you haven't explained the meaning of Flags or any part of the domain).
A simple query to get all flags for a particular phone number would be:
from PhoneNumber pn
inner join PhoneNumberFlag pnf
on pn.pkPhoneNumber = pnf.fkPhoneNumber
inner join Flag f
on f.pkFlag = pnf.fkFlag
where pn.PnValue = '555-555-5555'
As for the RDBMS you are looking to go with, that is very dependent on MANY factors. What's your environment? What do you already have? MySql is a very different type, as it is open source. Oracle, SQL Server, these are not. I'm not sure about Oracle, but SQL Server has a free edition (SQL Server Express) that you could leverage, but it is limited. RDBMS licensing can get costly very fast. There are too many questions that need answering before a sound recommendation on that front can be made.