I've decided to close this question as its become way to broad and most of the questions I had regarding this I figured out the answer to them. No need to reply but do use as a reference or add to this in case you ever get stuck with something similar. I'm subbed to this post so will be notified and try help out

tl;dr
I have a class which doesn't have a table and all the data for that page type is being stored in tables prefixed with _obsolete_ why does this happen and how can I fix it? I need the class to have it's own table and have the data go in there, not randomly into some _obsolete_ tables
___

I had created a class called Content which was to be used to create general content, it works in the same manner that Page does except under a different name for clarity and just to get CMS users into the mindset that they're creating content and not actual webpages (because authors != web developers && content != code).

Initially during development I wasn't paying all that much attention to which of the two page types were being used. Then I found out this handy thing existed

Config::inst()->update('Page', 'hide_ancestor', 'Page');

So I thought "this is fantastic! I can go ahead and remove one of the two things that do the exact same thing in one go all across the site!"

Once I put that in a lot of things started breaking, I quickly concluded it was because the Page and Content types were both being used, so I removed that code above and changed all Page page types to Content then readded the code and all worked fine.

During this whole process I saw a lot of tables being prefixed with _obsolete_ but just figured it was there as a reference for something the CMS needed so I left it alone.

This all happened a couple months ago, today I was looking through the database tables and noticed that Content wasn't there, I decided to check the _obsolete_ tables and noticed that since all that happened everything which was created using the Content page type was going into those _obsolete_ tables and it is only storing the page ID, no idea where the actual content is being shipped of to...

This behaviour is not ideal.

Running dev/build no longer creates a Content table, it just continues to populate the obsolete tables.

I tried removing the Content.php file, running a build then readding it and doing another build in the hope SilverStripe would recognise it and add the table in, but that didn't work either.

So how does one resolve this issue? Is it some caching thing I could simply delete? I can't have data scattered across a database or it'll get really messy in no time.

So I've got an update on this and think I might know what the issue is...

I created a new page type, say, WeeklyReports which extends Page. In this page type it doesn't contain a $db method as it only needs the title, the data for this comes from elsewhere.

Now, I assume that because I haven't used $db there's no need for SilverStripe to create a WeeklyReports table and therefore falls onto using the Page table... the same _obsolete_ table that the Content page type saves to...

Is this the reason why the Page table is used - because I don't have any $db set in the Content and WeeklyReports page types?

I've taken out this

Config::inst()->update('Page', 'hide_ancestor', 'Page');

and ran a dev/build which put a Page table back into the database. Created a new article and see that the ID of the article has been stored in the newly created table.

So I guess I've kinda figured out my own question here but what I don't understand is that in Page just the ID is stored... where's the actual data held?? Answer: In SiteTree

Also, now that I found out why my content was being put into _obsolete_ tables is there a safe way I can transfer them to the Page table in order to get rid of them? I don't like having tables I don't need especially when they're prefixed with the word 'obsolete'... I can foresee there being a time someone deletes them thinking they are actually obsolete lol