MySQL Performance: Single Object With Multiple Types - JOIN scenario -

with following type of table design:

http://www.martinfowler.com/eaacatalog/classtableinheritance.html

let's use following schema sake of example:

create table `fruit` (   `id` int(10) unsigned not null,   `type` tinyint(3) unsigned not null,   `purchase_date` datetime not null ) engine=innodb default charset=utf8;  create table `apple` (   `fruit_id` int(10) unsigned not null,   `is_macintosh` tinyint(1) not null ) engine=innodb default charset=utf8;  create table `orange` (   `fruit_id` int(10) unsigned not null,   `peel_thickness_mm` decimal(4,2) not null ) engine=innodb default charset=utf8;   alter table `fruit`   add primary key (`id`);  alter table `apple`   add key `fruit_id` (`fruit_id`);  alter table `orange`   add key `fruit_id` (`fruit_id`);   alter table `fruit`   modify `id` int(10) unsigned not null auto_increment;  alter table `apple`   add constraint `apple_ibfk_1` foreign key (`fruit_id`) references `fruit` (`id`) on delete cascade on update cascade;  alter table `orange`   add constraint `orange_ibfk_1` foreign key (`fruit_id`) references `fruit` (`id`) on delete cascade on update cascade; 

here, 'apples' , 'oranges' types of 'fruit', , have unique properties, why they've been segmented out own tables.

the question is, performance standpoint, when performing select * fruit query, better to:

a) perform left outer join on each typed table, i.e. apple , orange (in practice, may dealing dozens of fruit types)

b) skip joins , perform separate query later each fruit row in application logic, fruit row of type apple, select * apple fruit_id=...?

edit: regarding specific scenario, won't go excruciating detail, actual application here notification system generates notifications when events occur. there different notification type each event type, , each notification type stores properties unique event type. on site lot of user activity, there millions of notification rows.

have 1 table columns 'common' attributes (eg, type='apple', purchase_date=...), plus 1 text column json containing other attributes (eg, subtype='macintosh') appropriate row in question.

or might make more sense have subtype common attribute, since many fruits have such (think 'navel').

what doing "inheritance"? it's great in textbook, sucks in database. sql predates inheritance, object-oriented, etc.