Chasing my tail with this design

I've never been great at DB Design, I try though.
Here is my situation.
We manufacture hardware devices(startup Co.). I write the firmware for the
devices and generally all other software issues.
As we are growing, we were having more and more customers wanting
"customized" versions of the firmware, being a startup, we aren't about to
say "no" yet.
Rather than edit the source everytime someone needs a custom change, I
decided to write a Firmware Editor that would take the data entered for the
customer, store it in the database and when need, generate source code
header files to be used in batch builds when we release new version of the
firmware.
The device performs a set of "tasks" and each task is broken down into
several sets of "operations".
There are 3 models of our device, each performing exactly the same "tasks"
and "operations" but with different "power output" - in the future we
foresee users wanting to further customize the firmware on a per-model
level.
So for example, customer A might want Model1 to run task # 4 for 30 minutes
Model2 to run task #4 for 20 minutes
Model3 to run task #4 for 45 minutes.
The device is not interactively programmable by the users as 90% of our
customers "like it how it is"
I have roughed out the first database design pass, it's like this:
[Tbl_Customer]
PK CustomerID
CustomerName
// configs allow a customer to have "sets" of firmware for their different
needs. The example above w/ "customer A" and "Model1/2/3" was an example of
a "Config"
[Tbl_CustomerConfig]
PK ConfigID
CustomerID
ConfigName
[Tbl_DeviceSettings]
PK DeviceSettingID
FK ConfigID
FK DeviceID
BootScreenText
BaseFreq
[Tbl_Devices]
PK DeviceID
DeviceName
[Tbl_Tasks]
PK TaskID
FK DeviceSettingsID
TaskName
TaskDuration
TaskOppCode
// each task is comprised of many "Task Operations" - customers are wanting
us to change these as well
[Tbl_TaskOperations]
PK TaskOperationID
FK TaskID
StartFrequency
EndFrequency
StartAddress
Now, the problem is... I want to have ALL customers in the system, even the
ones that don't want changes(yet) so that if/when they want changes, we can
deliver the new firmware fast and not worry about entering them into the
system, etc. There are other advantages as well.
Based on my current schema, I would be storing data for the 90% of customers
that DON'T want to customize their data, this seems so wasteful. And even
if they did want to edit just one of the 30 available tasks, I would be
storing all those duplicates.
Another problem is that If I need to make a change to non-customized task, I
would need to make it for ever device, in every config for each customer.
Stupid.
I though about making a "base" customer, "base" config, "base" tasks with
"base" operations. All customers would have FKs to these "base" records
until they decide they want something custom, then at that point I edit the
data and it creates a new record for only the data that has changed. Does
that make sense?
I hope someone understands what I'm after, it's hard to explain.
Thanks for reading this far!
Steve"Steve" <sss@.sss.com> wrote in message
news:OYSuOHHyFHA.1132@.TK2MSFTNGP10.phx.gbl...
> I've never been great at DB Design, I try though.
> Here is my situation.
> We manufacture hardware devices(startup Co.). I write the firmware for
the
> devices and generally all other software issues.
> As we are growing, we were having more and more customers wanting
> "customized" versions of the firmware, being a startup, we aren't about to
> say "no" yet.
> Rather than edit the source everytime someone needs a custom change, I
> decided to write a Firmware Editor that would take the data entered for
the
> customer, store it in the database and when need, generate source code
> header files to be used in batch builds when we release new version of the
> firmware.
> The device performs a set of "tasks" and each task is broken down into
> several sets of "operations".
> There are 3 models of our device, each performing exactly the same "tasks"
> and "operations" but with different "power output" - in the future we
> foresee users wanting to further customize the firmware on a per-model
> level.
> So for example, customer A might want Model1 to run task # 4 for 30
minutes
> Model2 to run task #4 for 20 minutes
> Model3 to run task #4 for 45 minutes.
>
> The device is not interactively programmable by the users as 90% of our
> customers "like it how it is"
>
> I have roughed out the first database design pass, it's like this:
> [Tbl_Customer]
> PK CustomerID
> CustomerName
>
> // configs allow a customer to have "sets" of firmware for their
different
> needs. The example above w/ "customer A" and "Model1/2/3" was an example
of
> a "Config"
> [Tbl_CustomerConfig]
> PK ConfigID
> CustomerID
> ConfigName
> [Tbl_DeviceSettings]
> PK DeviceSettingID
> FK ConfigID
> FK DeviceID
> BootScreenText
> BaseFreq
> [Tbl_Devices]
> PK DeviceID
> DeviceName
> [Tbl_Tasks]
> PK TaskID
> FK DeviceSettingsID
> TaskName
> TaskDuration
> TaskOppCode
> // each task is comprised of many "Task Operations" - customers are
wanting
> us to change these as well
> [Tbl_TaskOperations]
> PK TaskOperationID
> FK TaskID
> StartFrequency
> EndFrequency
> StartAddress
>
>
> Now, the problem is... I want to have ALL customers in the system, even
the
> ones that don't want changes(yet) so that if/when they want changes, we
can
> deliver the new firmware fast and not worry about entering them into the
> system, etc. There are other advantages as well.
> Based on my current schema, I would be storing data for the 90% of
customers
> that DON'T want to customize their data, this seems so wasteful. And even
> if they did want to edit just one of the 30 available tasks, I would be
> storing all those duplicates.
> Another problem is that If I need to make a change to non-customized task,
I
> would need to make it for ever device, in every config for each customer.
> Stupid.
> I though about making a "base" customer, "base" config, "base" tasks with
> "base" operations. All customers would have FKs to these "base" records
> until they decide they want something custom, then at that point I edit
the
> data and it creates a new record for only the data that has changed. Does
> that make sense?
> I hope someone understands what I'm after, it's hard to explain.
> Thanks for reading this far!
> Steve
>
>
Another thing that I thought of was to have a duplicate Tbl_Task that would
hold the unchanged, non-custom data, then another table that had all the
CustomTasks, but that doesn't seem like a good solution, seems hacky...|||How about having a discrete set of customizations (the operation, task, etc
collection/unit/whatever) and associating one (or many) with each customer.
That way one customized task could serve multiple customers, starting with a
default configuration for that 90%:
CREATE TABLE dbo.Customizations
(
id int PK
, name char unique
, ... attributes
)
CREATE TABLE dbo.Customers
(
id int PK
, name char unique
, customization_id int (FK to Customizations) -- drop this column if you go
1-many
)
For a 1-many relationship create a cross-reference table:
CREATE TABLE dbo.CustomerCustomizations
(
customer_id int (FK to Customers.id)
, customization_id int (FK to Customizations.id)
, PK(customer_id, customization_id)
)
"Steve" wrote:

> "Steve" <sss@.sss.com> wrote in message
> news:OYSuOHHyFHA.1132@.TK2MSFTNGP10.phx.gbl...
> the
> the
> minutes
> different
> of
> wanting
> the
> can
> customers
> I
> the
> Another thing that I thought of was to have a duplicate Tbl_Task that woul
d
> hold the unchanged, non-custom data, then another table that had all the
> CustomTasks, but that doesn't seem like a good solution, seems hacky...
>
>|||Hello KH,
Thank you for your post. I have been messing with the design this morning
and have begun doing something like you suggested.
I'm looking forward to having everything work ;)
Thanks again,
Steve
"KH" <KH@.discussions.microsoft.com> wrote in message
news:DB5EBD4B-615F-414F-8179-DA895098CD2B@.microsoft.com...
> How about having a discrete set of customizations (the operation, task,
etc
> collection/unit/whatever) and associating one (or many) with each
customer.
> That way one customized task could serve multiple customers, starting with
a
> default configuration for that 90%:
> CREATE TABLE dbo.Customizations
> (
> id int PK
> , name char unique
> , ... attributes
> )
> CREATE TABLE dbo.Customers
> (
> id int PK
> , name char unique
> , customization_id int (FK to Customizations) -- drop this column if you
go
> 1-many
> )
>
> For a 1-many relationship create a cross-reference table:
> CREATE TABLE dbo.CustomerCustomizations
> (
> customer_id int (FK to Customers.id)
> , customization_id int (FK to Customizations.id)
> , PK(customer_id, customization_id)
> )
>
> "Steve" wrote:
>
for
about to
for
the
"tasks"
our
example
even
we
the
even
be
task,
customer.
with
records
edit
Does
would