This is really a domain modeling question masquerading as a data modeling one. If you really were modeling animals, then you could put the whole thing in one an

This is really a domain modeling question masquerading as a data modeling one. If you really were modeling animals, then you could put the whole thing in one animals table, with self-referencing columns. This is because you only have one 'type' of domain concept, with details that not all instances of the class will share. So you leave those columns NULL. So you do one animals table with an animal_id and species_type columns, the species_type column could be a enumerated string field or foreign key to a species table, and pet as a boolean field. Now soon you might want to know 'whose' pet it is, so you'll need a human table to store the humans, and then you'd need a human_id field on the animals table to store that information. You 'could' use a pets join table if you want pets to be a first class domain concept. All these decisions revolve around what your app will be doing. Ideally you'd have a REST web architecture, this makes domain modeling a bit easier. Anything that has it's own web page, give a database table.