I'm very anal about trying to maintain development standards when designing applications. This puts me in a difficult situation because every company I've worked for let's standards slide (or doesn't care) and especially in regards to data. This compromise is usually attributed to the lack of time that's available but other times due to the complexity of the data.

So, I am again faced with a project that may compromise the relational database model and I would like input from other people who've been in my situation. The situation is that my company currently has several stand alone applications geared towards different customers. Each customer has similar yet different data requirements but we would like to merge all of our separate applications into one and thus house all of this data under one database. I am perfectly o.k. with this concept but what is the best approach for designing the central database?

For example, we have a table for entering time sheets. Company A's table may look like:
Customer Number, Employee Name, Hours, Equipment Used, Description, Work Expense, Back Charge, Additional Charge.

However, Company B's table may look like:
Customer Number, Employee Name, Hours, Equipment Used, Description, Additional Charge.

My boss would like to make an aggregate table that looks like:
Customer Number, Employee Name, Hours, Equipment Used, Description, Desc1, Desc2, Desc3, Charge1, Charge2, Charge3.

Obviously, doing it his way would mean that all of the last columns for Company A would mean something entirely different for company B within the same table(entity). I've ran into this situation before and it became quite confusing when fixing data issues. Also, this situation requires a lot of upfront data checking by the UI and prohibits using solid abstract layering standards. On the other hand, this lowers the amount of tables needed and makes updating a cinch (possibly).

Is there a better way to design this?

I worked with one company that did something similar where they had attribute 1 to attributeX columns with a type field. Depending on the type, attribute1 meant something different in record 1 than 2. This was a mess because all of these fields were integers and required complex joins in order to bring in the descriptions. Then, if we needed to add another bit of info for company A, we had to add another attributeX field and re-program all of the UI's to handle this change.

Thank You for your input.