Sql correct pratice when making a collection of tables - mysql

Question

I wasn't sure what to call this post but here is my problem:
I have two tables: Online_Module & Offline_Module These two tables are used in my program to determine if the learning module has to be taken online or on location.
Now I also have a table called Academy. An Academy consists of many modules. For this I wanted to create the following sub-table: Academy_has_Module
And here lies the problem. Because the Online_Module and Offline_Module are not in the same table one of the values in my Academy_has_Module will always be null
Here are some pictures that show the buildup of these tables:
As you can see, one of the values will always be null. I want to know, what is best practice in situations like this?

Answer 1

1) create a table Module, holding fields commong for online and offline module:
id INT,
description
material
status
category
2) then keep the offline/online module tables (edit: minus the fields -except the id field - you are now keeping in the Module table ), but make them FK reference the new Module table, using the Module table as an intermediate link.
Edit:
Now, not to overwhelm you with a lot of stuff, but there are several questions you have to Q&A yourself, ie:
- can module be only offline/online?
- if yes, do i want to enforce it 100% in DB?
Because with my solution, you can have one Module and have it referenced by several Offline/Online modules. There are ways to solve it, but i think they would go far beyound what you asked, i am just mentioning it so you know..
As to getting the information (maybe not the best, but this is my level for now, if anyone knows better, feel free to teach me a new trick :)). *Notice: ugly coding, too tired for full up coding style :D *:
select *, case
when OffM.Id is null and OnM.Id is null then 'No module!'
when OffM.Id is not null and OnM.Id is not null then 'Too many modules!'
when OffM.Id is null and OnM.Id is not null then 'Online module!'
when OffM.Id is not null and OnM.Id is null then 'Offline module!'
end --probably a different, better way to compare?
from Academy_has_Module as AHM
join Module as M
on Academy.Module = M.Id
left join OfflineModule as OffM
on OffM.ModuleID = M.Id
left join OnlineModule as OnM
on OnM.ModuleID = M.Id
But now, from what i understand, if you added an ModuleType into the Module table, ORM frameworks (i dont really use them that much to be honest, so no 1st hand experience), can use this to return you an object of the correct class. But this is going much deeper into the whole architecture and technology used in your project and is outside the scope of this question and even my actual experience.
EDIT2:
Ok, one more thing that came to my mind: Is it not reasonable to change the online/offline module table structure to be same somehow? for instance online module :
-could have a mentor/responsible person as weel
-could be open from - to datetime
-offline module doesnt have a name?
-location for online module would be ie 'Online'
and just merge the tables together with a ModuleType - either constraint or a FK to an enumeration table (not sure what the right term is in English). Maybe a little bit forced, but (again, a lot of this depends on overall requirements, i have never seen even a simple table being added in a single iteration, it always influences something and it propagates inside the design) could make your life simple. Sometimes, its better to waste few bytes of space per record then trying to be too cute and getting bit in the posterior down the road.
Have a nice day

Answer 2

This is superclass/subclass design (or super-entity/sub-entity if preferred). To expand on #VladislavZalesak's answer, place the common attributes into a super-entity table. But don't forget to implement the proper data integrity checks.
create table Module(
ID int not null primary key,
ModType char( 1 ) not null,
Name varchar( 45 ) not null,
Description text,
MaterialID int,
StatusID int,
CategoryID int,
constraint TypeCK check( ModType in( 'O', 'F' ))
);
create unique index ModuleType_UIX on Module( ID, ModType );
Now, if ID is the PK, it must be unique. So why, you ask, do we create a unique index with ID and ModType? So we can reference them as a group:
create table OnlineModule(
ID int not null primary key,
ModType char( 1 ) not null default 'O',
Price double,
Time varchar( 45 ),
constraint OnlineTypeCK check( ModType = 'O' ),
constraint OnlineTypeFK foreign key( ID, ModType )
references Module( ID, ModType )
);
create table OfflineModule(
ID int not null primary key,
ModType char( 1 ) not null default 'F',
StartDate datetime,
EndDate datetime,
Mentor varchar( 45 ),
constraint OfflineTypeCK check( ModType = 'F' ),
constraint OfflineTypeFK foreign key( ID, ModType )
references Module( ID, ModType )
);
Now your Acadamy_has_Module table needs only the one FK to Module, which gives most of the information you need, even the fact that it is offline or online.
Both submodules have an identity relationship with the module table, not just by ID, which would be technically sufficient, but also by module type, which implements the sub/super relationship. The check constraints keep the structure enforced.
You can create views which join module to either submodule to show all the fields of each type of submodule.
It's extensible in that you can add new submodules. But if you think that would be likely, you might want to create a submodule_type table and define the ModType field of Module as an FK to that table. That would eliminate having to alter the check constraint of Module every time you added a new subtype.
Kinda cumbersome when you first look at it but it's flexible and solves some up-front design problems.