I've two tables which look type of similar and i believed about mixing them and thought i'd acquire some input from everybody. This is what they presently seem like:

Issues

Id  | IssueCategory   | IssueType | Status | etc..
-------------------------------------------------
123 | Copier          | Broken     | Open   |
124 | Hardware        | Missing    | Open   |

CopierIssueDetails

Id | IssueId | SerialNumber | Make | Model    | TonerNumber | LastCount
---------------------------------------------------------------------
1  | 123     | W12134       | Dell | X1234    | 12344555    | 500120

HardwareIssueDetails

Id | IssueId | EquipmentNumber | Make | Model | Location  | Toner | Monitor | Mouse 
-----------------------------------------------------------------------------------
1  | 124     | X1123113        | Dell | XXXX  | 1st floor | 0     | 1       | 0

Exactly what do everyone consider mixing both of these tables into one. Will it be advisable or is it more beneficial to ensure that they're separated such as this? Thanks ahead of time for just about any suggestions.

Ultimately the question boils lower to "Is a 1-to-one a treadmill-to-many ratio?" If there's ever the chance to possess several products inside a given table associated with the products in another table, have them separate. Otherwise, then mixing them would simplify your queries.

I'd require a compelling reason to mix them, because they do not look exactly the same. Maybe there's a compelling reason, however i aren't seeing one offered.

In mechanical design, one faces your decision of whether two parts are identical enough to become known as through the same part number, or will vary and deserve different PNs. The rule to determine this really is "Form, Fit, Function."

  • Form: Could they be "exactly the same enough?"
  • Fit: Could they be interchangeable?
  • Function: Will they carry out the same purpose, satisfy the same need?

You can test using this criteria for your schema.

One factor I look into these situations is "The way this stuff evolve?". For instance, if you want to give a new column for Copy machines, what's the likelihood that Hardware will require that same column? How about confirming, would you routinely have to mix the data, or would you routinely have separate reviews for that two sorts?

When the a couple of things appear prone to evolve/be utilized individually, then I would suggest disregarding the truth that they appear much the same Or else you finish track of special cases littered throughout your queries.

You could, though you might want to think about making the posts a little more generic to ensure that you do not have many empty posts. For instance, you will know Copier's do not have monitors or rodents, therefore it makes little sense for any copier row to possess a monitor/mouse column. You can make individuals posts more generic, by altering it to 1 column known as "HardwareType" using the values:

= Monitor,

1 = Mouse,

2 = Monitor &lifier Mouse,

3 = Copier

(You can then put this inside a lookup table, to keep an eye on your IDs).

What you be thinking about are:

1) While mixing these tables increase speed from the application?

2) While mixing these tables increase upkeep of the applying?

When the tables are generally large, and employed for different tasks, it might not be smart. For tables which are "roughly exactly the sameInch when it comes to concept, then it is pretty good to mix them as lengthy because it does not impact performance, so that as lengthy while you avoid lots of unnecessary posts which are only specific to particular products although not others.

Well, it is dependent how large you anticipate this complexity to go into future.

If it is just likely to be couple of more problem types varying with couple of specific fields and getting many common fields, it seem sensible to mix these into one and then leave the fields null that don't apply inside a particular situation.

Other approach would be to mix all common fields into one table, and add another common additional particulars table with structure like:

IssueID
FieldName
FieldValue_Text
FieldValue_Number
FieldValue_Float

and might be an expert table for further area names with posts like:

FieldID
FieldName
DataType

Ultimately, I'd say it the CONTEXT that will justify any design and it is hard to assert your question without searching in the truth.