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.
There are different patterns you can use to design a database. For example you can represent objects with a Table per type style design or with a table per heirarchy design. There are pros and cons to each but I haven't seen that one stands out as the "right" way.
However, with your design, if the objects are essentially the same, I would try to use the same object and ditch the type column. Or if they are truly different, it seems like the foreign key columns would be related to different tables, so you'd want to have different tables with clearly defined Primary Key, Foreign key associations.
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.