My question is for designing something in MSSQL server.

I work at an engineering company that designs embedded systems. Basically, we have 3 different hardware components in a product: one is for communication on a network (GPIB, Ethernet, Modbus...), one is for measurement/control functions, and the third is for miscellaneous stuff (like diagnostics and logging). Each piece of hardware has multiple firmware versions available. Each firmware has a set of registers used for configuration and a set of defaults.

I want to create a database to track the firmware, hardware, default configs, and register maps. I can create three separate tables for firmware, like commHardware, controlHardware, miscHardware, and then create tables that relate to these (i.e., commFirmware with a foreign key to commHardware and commDefaults with a FK to commFirmware).

Or... I can structure my tables so that there's one table for hardware, one for firmware, one for register maps, one for default configs, and one for hardware role (comm/misc/control).

The representation will be the same no matter which option I choose, so I don't have to shoehorn one design to fit the other. Right now, I'm leaning toward option 1, for two reasons.

  1. If I confuse something, it might not work - if I try to download comm firmware 01 onto a control board, it'll be blatantly screwed up. I don't think it is physically possible to do so - the processors are different.
  2. If I confuse something, it might actually work... for a while. Downloading the miscellaneous registers onto a communications board can be done, but it'll screw up communications ("Oh, you wanted to suppress overflow alarms? Too bad, here's a new MAC Address.")

In writing this, I've almost convinced myself, but I want to get a second opinion. Is the first approach superior in a way I'm missing? I'm looking for problems that could cause:

  • Obvious performance issues
  • Data integrity problems
  • Maintenance nightmares
  • Software development headaches
  • Angry future coworkers visiting my house with hatchets, torches, and/or pitchforks in hand.
  • How may records are you expecting? What will this db do? Is it just for record keeping? Or will other software/systems integrate to it? What will this do that excel or word cant? Commented Dec 20, 2017 at 2:30
  • All of the problems you are trying to avoid are possibilities. I highly reccomend you consider the lowest tech and simplest option. In my experience one-off custom dbs create more problems long term than they solve. Commented Dec 20, 2017 at 2:38
  • @Peter: I'm not expecting a ton of records: if we released more than one firmware a week, I'd be astonished. We want to automate the mundane tasks, keep electronic records, which involves several separate applications testing the units in different conditions and recording their results. I'm trying to get a one-stop shop for saving and retrieving data. Commented Dec 20, 2017 at 15:46
  • This question may have an answer here Commented Dec 21, 2017 at 14:15

2 Answers 2


I think you want to go with your first option. Here's why:

You should design your database with a primary goal of maintaining data integrity. Subtle data corruptions can be harder to debug than source code logic errors. This is because corrupted data may only cause a detectable problem when a series of conditions occur at runtime. Often you can't repeat these reliably.

The best way to focus on data integrity is to create a properly structured database. If your data is going to be edited at any time, then you're best to start with a design that's in Third Normal Form (3NF) at least. In general, you should have a table for each distinct type of thing that you have data about.

Sometimes, you may have two or more different types of things with similar attributes (data items). This puts you in the position of deciding where you make your trade off. Combining the facts about your things into one table means fewer tables. Fewer tables will mean less code as long as the different types of things are and continue to be similar. If you need to start moving in the direction of each type of thing having its own distinct set of attributes, then your code will become more complex and hard to maintain, with lots of branching logic.

It's important to remember that two different tables having the same set of attributes might be coincidental to your system or it might be consequential to your system. Database structure design is not optimized in the same way as code reuse. Cramming logically distinct but structurally similar data into the same table is not a good practice. If you have two or more semantically distinct tables with very similar or even identical structure and your programmer's spidey-senses are tingling too much, then satisfy your urge for code reuse by subclassing in your code, but leave your apples and oranges in their own tables, rather than cramming them into a "fruit" table.

In a case where your two (or more) types of things are different from one another, then having one table for each type of thing is probably an excellent place to start. This will keep your logic simple and your data clean, which makes for a high quality system.

  • 1
    I agree. A logical and well designed system will be beneficial in the long run. Especially to whoever becomes responsible for maintaining this in the future. Commented Dec 20, 2017 at 19:16

I'm not sure I really understand the specifics to the case you have outlined. But if I do, then I want to draw your attention to a pattern that comes up over and over again in the effort to describe some aspect of the real world. Here goes.

Comm, control, and misc sound like different specializations of something whose generalized name I do not know. This is a common and well known pattern.

I'm going to point to an answer I put up over in the DBA area. The specifics may be different, but the recommended techniques may equally apply to your case.

I'm not going to tell you whether to go with one table or four (three specialized and one generalized). Instead, I'm giving you the basis for deciding yourself.

Your case is a little more complicated than most, because your three way split occurs more than once. At first glance, that looks like there's a hidden entity somewhere in your case. But I haven't thought it through, and thinking takes time.

Finally, here's thelink Is it a bad practice to have several mutually exclusive one-to-one relationships?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.