Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m structuring a database, and found that I have two different objects I’m trying to model. Each one consists of the same things (a varchar and a couple of foreign keys), and will do so for the forseeable future.
I’m (as of now) going to put them in the same table, with an extra ‘type’ field, but I was wondering if there’s standard practice for this.
Edit: To clarify, they’ll both be used in the same way as well, with the only differences being where/when they’re displayed.
The rule is as follows:
If the objects are truly different and will act in different ways, regardless of how similar they are in implementation, you should put them in two different tables.
Apples and oranges.
If the objects are at any point being compared to one another in the same context or in aggregate, then you store the base class in one table with a code field, and store the subclasses in two more tables using foreign keys.*
A “fruit report” for apples and oranges. How many fruits do we have? How many fruits of any kind come from California?
*NB: There are actually many ways to attack the subclassing problem in a database. The point wasn’t so much which strategy you’re using as it is you treating them as a common supertype or not.