SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Application development, all features inside the database or seperate them


Application development, all features inside the database or seperate them

Author
Message
Megistal
Megistal
SSCertifiable
SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)

Group: General Forum Members
Points: 7719 Visits: 2642
I'm seeking your advice and / or experience about why and how for the following:

Let says you're developing a software. That software has core features that can be augmented with additional "selectable" (a la carte), from a marketing perspective, options.
Core features are always active.

For instance you could have that scenario:

Customer #1: Core features + option A, B, D
Customer #2: Core features
Customer #3: Core features + option D

Which database approach / design would you use and why?
- All features always available inside the database (therefore each deployment has always everything, same schema everywhere, but options are enable or disable by the application somewhere else)
- Only usable options that the customer paid for are deployed in the database, therefore the database schema (tables, sp, views, indexes, name it) is different from installation having different option selected.

In the example above, all 3 customers will have distinct database schema.
Customer #4: Core features + option D will have the exact same schema as Customer #3

I tend to see the "all features available" with far less maintenance overhead but I'm seeking advices and experience on that topic in case of something I might overlook.

Regards,
RandomStream
RandomStream
SSCrazy
SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)

Group: General Forum Members
Points: 2849 Visits: 648

I came from an environment where each customer has different and evolving customization needs. The application was designed in such a way that each customer can demand their own mix of feature set. The approach was to include everything in each release. Custom scripts were maintained at each customer's site (within the database). Paid custom features were enabled by a license key.The feature set mix is transparent to developers - they only need to write code. Deployment team would alter the feature set as new or new custom features become available. As for the feature set, there was a default feature set that everyone needs. On top of that, customers can define their own mix. Every feature set can call another set using a 'include'. Of course, duplicate features fro the 'included' feature set will be overridden.

No matter how thorough you are in the design phase, sooner or later you run into situation that demands exception handling. So it was not unusual to see customer name hardcoded into a script (we had to check installation code, which is based on customer name) that get deployed to all customers during product upgrade. As long as it didn't break anything, we had never had any complaints.



Megistal
Megistal
SSCertifiable
SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)SSCertifiable (7.7K reputation)

Group: General Forum Members
Points: 7719 Visits: 2642
Thank you for sharing me this experience.

You're right there will be exceptions down the road.
Sue_H
Sue_H
SSC Guru
SSC Guru (67K reputation)SSC Guru (67K reputation)SSC Guru (67K reputation)SSC Guru (67K reputation)SSC Guru (67K reputation)SSC Guru (67K reputation)SSC Guru (67K reputation)SSC Guru (67K reputation)

Group: General Forum Members
Points: 67200 Visits: 13960
Megistal - Tuesday, January 23, 2018 6:29 AM
Thank you for sharing me this experience.

You're right there will be exceptions down the road.


I worked for a couple of commercial software companies - they used the "all features" approach. It seemed like a more standard implementation this way and then used customized scripts for different customers to enable/disable. It was relatively easy to add or remove features and the maintenance would read the settings so implementing that was standard across the board.

Sue



Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum








































































































































































SQLServerCentral


Search