sql server misc: I hope that I can get some help with database design.

Specifically I have been working on a database which holds all company
records in single table, this is then linked to a table containing
company type indicators e.g. Client, Supplier etc.

I'm about 95% sure that we understand all the types we need, so am
thinking about denormalising the tables so that the company record
table has a field for each type, rather than linking to another table.
"Denormalise till it hurts, normalise till it works" is a quote I keep
coming across, which makes sense.

Here is the bit where I would welcome some opinions. Should all
company records be stored in one table, or should I have multiple
table, i.e. one for clients, one for suppliers? The catch here is that
a single company can be both a supplier and a client. Reason for
asking? I'm a web developer not a DBA, although I have worked directly
with design on Oracle, Access and SQL Server so know the basics,
whereas my boss spent the early part of her career as a DB2 developer
(if that's the correct term). My opinion is that due to the data being
stored is exactly the same regardless of the type(s) the company is
designated, so a single table makes sense, also helps with RI. However
I have been asked to review this as my boss doesn't think this is the
correct route.

Any opinions, pros and cons would be warmly welcomed.

Thanks,
Steve

[quoted text, click to view]

What type of data is it? Do any types of companies other than suppliers
and clients have it? Do any types of non-companies have it?

Depending on the answers, the right answer might be to store it in the
company table, or in an intermediate table (e.g. suppliers_and_clients),
or in a more general table (e.g. addresses - which could also cover

[quoted text, click to view]

It holds company names, contact details for switch board etc and main
contact address. Other addresses and contacts are linked but stored
elsewhere, e.g. contacts are stored in another table and link to the
company using a foreign key, alternate address are also stored
elsewhere. The data (fields) are common to the stored data, anything
that is related to just suppliers is stored else where, and the same
for clients.

My way of thinking says that we already have it pretty much the "right"
way, common data in a common table with more specific data - to the
type - held in specific tables.

As I mentioned above my boss has questioned this approach which made me
think, "why would anyone do it another way?" I'm no DBA and I guess
I'm looking for a comfort blanket and something to go back to my boss
and say "There isn't any design issue with our current database" (at
least in this restricted view) :-)

Cheers,
Steve