I saw the recent post about the person questioning his boss's solution (I believe my solution is better than my boss, so should I ignore him?) and decided to ask something similar but not as "clashing" as it sounded in the above link.
To put it simply and more conceptually:
We have a web app that does phone billing for many different clients. The thing is, the person that started the project didn't consider that there are only 9999 possible phone extensions in our design (a bit naive, I know). We have come across a point where different clients's users will have to share the same
extension number. In the DB level, the
extension number is fixed as
unique and the
Extensions table has a foreign key to
The easiest solution as we saw was to remove this
unique constraint and allow
extension numbers to be duplicated because we can still check and validate to see which
User belongs to. However, the person that oversees my work believed it would cause future problems if we simply allowed for duplication. He suggested I create an intermediary table that links two tables together, namely
UserProfile (which has a foreign key to User and
Client) and the
Since my way seemed easier to do, I created a branch of the project to test if it works fine, which it does.
Then I started implementing the other way and came across some complications, system-wide modifications, but I still think it's doable. The person that oversees my work is a sys admin that does some programming. I'm the full-time programmer, though without much experience (still young ;) ). It would be cool if I had some outside perspective on my dilemma?
Thanks a lot guys.