I have a database where customers buy items that have different components/licenses installed. These are customizable so a customer could have an item with option/licenses 1,2,3 and other items with just options/part 1 and 2 and so on.
The options can vary greatly from customer to customer and I am wondering what is the best way to track these options. I could just add multiple fields to the item database for these options but I am thinking there is a more efficient way to do this.
use a components-table like partlists:
tbl_customer => 1:n => tbl_licence/items => 1:n => tbl_components
fields in the tbl_licence will only work for a small number of components that will “never” change
in case of Changes you have to customise your project.
with tbl-Components there is no need for customising.
It#s only an insert in a table like “tbl_base_components”
OK, how about this wrench I just thought of. The licenses can be either assigned to specific hardware or a specific user (customer contact). My thought it to have two many to many relationships.
hardware M:M Licenses and one customer contact M:M licenses. This would, of course, mean I will need to have a field in the license table that signifies if it is a hardware or user-based license.
Am I on the right track here or totally off my rocker?
The customer is not the user in every cases, only the guy who will pay for the licence.
Licences can have several types for using and configurations. it can be liecenced for a user | hardware | group of users | whole site depending on a type.
and it can have varios configurations.
Ex.
If a customer need 10 “single user licences” f?r his users, he will by 10 licences . each for 1 user. => tehy can have differnt configurations depending on the requirements
Or one “shared user licence” for max. 10 simultaneous users. all have the same licence cofiguration
The scope of the licence can be a harware to. depending on your model.
I agree. so going along those lines I think that a user could have various licenses assigned to them but not all users will have the same amount or same license assigned to them. In order to avoid extraneous columns that may have NULL data, this is why I was thinking that a few many to many relationships would help.