January 23, 2012 at 3:09 pm
Hi,
We have database in our company comprising of about 800+ tables. Reason being, we try to use same database for variety of our customers sharing about 75% of features(and about 30 customers with independent features). My questions are:
1) How do some one control architect of this ever growing database, with new features implemented quarterly?
2)How can DBA architect make sure DB sticks as close to industry standards. i.e. Non repetitive tables or columns.
3)If there is already some junk columns(or redundant tables/view/S.P.) created in DB, how does some identify them?
Any input will be appreciated.
Thanks
January 30, 2012 at 8:17 am
Kal Penn (1/23/2012)
We have database in our company comprising of about 800+ tables. Reason being, we try to use same database for variety of our customers sharing about 75% of features(and about 30 customers with independent features). My questions are:1) How do some one control architect of this ever growing database, with new features implemented quarterly?
2)How can DBA architect make sure DB sticks as close to industry standards. i.e. Non repetitive tables or columns.
3)If there is already some junk columns(or redundant tables/view/S.P.) created in DB, how does some identify them?
Any input will be appreciated.
Not easy objectives to accomplish.
DBA Architect has to have full power to approve and eventually reject proposed changes to the database. Goes without saying that DBA Architect has to actually check and approve every single proposed change and have in place a production deployment process that enforces such rules.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.January 30, 2012 at 9:01 am
1) I'd use the same database for all customers. If customerA has feature X and customerB has featureY, use separate tables. That way you can easily "turn on" features for customers if they need them later.
2) Hire a good architect that understands this. It's hard, and there is a lot of debate over how to actually handle some things in the industry, but this is all dependent on the person you hire.
3) What's junk? How do you define it?
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply