Redesigning a table that has a lot of columns (not always related) I'm new to database stuff so I apologize if I say anything ridiculous..

I work for a company that runs a website for a certain industry. We're not very large at the moment but our parent company wants to push our product out to more places. I'm worried about this because our database was never designed with ANY plan in mind (e.g, normalization doesn't exist, there are maybe 70 unused tables out of about 400- plenty of more unused columns on the tables we do use, etc.,) and we're running on a really shitty database program (pervasive SQL).

The company has at least recognized the need to move away from pervasive. We're planning to go to mariadb. To go along with this, there is a rare opportunity to potentially redesign some parts (or all of) the database but no one really cared to look into it- and that's how I ended up here.

SO, all that being said I just want to know if I'm on the right track here with my redesign so far.

Let's say we have a table that holds basic settings for companies on our system. Some of these settings are relevant to notifications (i.e what events will trigger e-mails for them), some are related to billing, some to how they create orders / what info they see on their orders, etc., This table has 334 columns and a LARGE amount of them only store a CHAR(1) which can be Y/N. (Side note: am I correct in assuming BIT will take up less space?)

What I've been doing is separating the parts (i.e, settings for orders go in their own company_order_settings table which has the company's id in it). The only thing is at this point I already have ~8 tables just for these different settings...is this normal? In general these things will (usually) be accessed separately so I'm not concerned about large joins. This large number of purely settings related tables will also happen when I refactor the user tables (which hold info on the users at said companies- in a similar number of columns).

If anyone wants more info let me know.
Not really an answer - but too big for a comment. Just a few ideas/discussion.

"our database was never designed with ANY plan in mind" - I hear yeh, sister! 

Been there, done that. Once worked with a Btrieve (precursor to Pervasive) system that had 35,000 (not a typo - that's thirty five thousand) fields in one table. Agree with @timpone - hesitant about tables with > 30 fields. Tables should be like women - tall and slim, not short and fat :-).

It's a lot of work to redesign. Start with core functionality - what's the minimum amount of tables required? I would consider PostgreSQL if I were you, but like @Austin, that's just my opinion.

Read up on the different RDBMSs - check out their functionality. Is there anything that Btrieve has that they do/don't? As far as I can see, the main thing that Btrieve brought to the party was arrays - they are a breach of the relational model and should be avoided at all costs in an RDBMS.

You say "a LARGE amount of them only store a CHAR(1) which can be Y/N. (Side note: am I correct in assuming BIT will take up less space?)". With space being so cheap these days, this is not really  an issue.