You’re offline. This is a read only version of the page.
A straight forward question for the experts here who know more than me.
We have a requirement for a table that will be 90% common across all businesses (possibly 100). Each business adds their own specific columns and then for each business there will be specific child tables, some possibly the same but mostly completely separate.
What is the best design:
I suspect the answer is the first, but then wont the base table get quite bloated and wide? But then on the second its a management nightmare.
Surely I am not the first with this issue, so what does the group wisdom have to say?
Thanks for the comprehensive reply. Aside from all the detail, I think I was mostly after confirmation that there is not some huge piece of existing functionality that I somehow missed 🙂
Hi,
You're right - this is a frequent problem that we face in many of our projects. The truth is there is no universal solution for that kind of challenge, so you must wisely consider all the pros and cons.
Think about these questions:
Let's meet in the middle - can you transpose your structure into core/common elements and department-specific ones? Create one core table that covers common interests and add another related tables that contain additional fields related to given variants. Remember you can embed the editable form of one table in another one.
Think about creating flexible form, where you can manage the settings for different LOB using your application rather than customizing all the one hundred variants. I mean creating a new entity "Line of Business", which gathers all the settings related to form for given LOB.
For instance, you create a Yes/No field called "Show Project Number". Then you write a JavaScript for the main form, which queries for the LOB settings based on the record data or current user's department, and applies selected business rules. In this case it will show/hide the chosen field.
You can create one hundred records of LOBs and bulk edit them easily, to change the business rules.
Personally, according to my experience, I opt for reusing as many elements as you can, instead of creating slightly different objects. Don't multiply instances of similar content - the best code is the one that has never been written. Probably the best option is to use the same data structure for all variants, but - if that would be ineffective in the future, you can always exclude part of your application if necessary and move it away to manage it separately.
Please note, we don't know all the details about your project, and the best solution for your case may be the opposite;).
Hi @camer314
There are more than one ways to achieve this as you said and every option has its ups and downs. Similar question was asked a bit earlier so, I'm being a bit lazy and, instead of typing my answer, I have pasted the link to that post with my answer (and alternative options suggested by others):
I hope you find the information useful. Please give it a thumbs up if you do and please accept it as a solution if it helps resolve your query as this will also help others with similar questions.
Kind regards
Gulshan
#1
WarrenBelz
146,645
Most Valuable Professional
#2
RandyHayes
76,287
Super User 2024 Season 1
#3
Pstork1
65,997
Most Valuable Professional
Share
Report
All responses (
Answers (
