Приветствую, форумчане.

Вопрос у меня к вам по части архитектуры БД — в моем случае MySQL. Работаю на данный момент с проектом, у которого объем БД меньше 1гб. При этом база имеет около ста таблиц.
До этого был проект с более увесистой БД, более богатым функционалом, а база его имела при всем этом всего 7 таблиц.
Далее опишу два подхода к построению архитектуры, а от вас хотелось бы услышать какой из них, по вашему мнению, правильней/предпочтительней и почему.
А, может, вообще всеравно какой из них использовать?

Допустим, нужно внести в базу информацию, по которой наш воображаемый движок будет понимать:

1) Какие шаблоны доступны для использования (например, в админке даем выбор какой шаблон будет использоваться для того или иного раздела)
2) Какие будут использоваться метатеги
3) И доступные для отображения баннеры

Мы можем создать три таблицы, по одной для каждого типа инфы:

templates   
id | name    
1  | temp1  
2  | temp2  

meta       
id | name        
1  | keywords    
2  | description  

banners
id | name
1  | banner1.jpg
2  | banner2.jpg

Или всего одну для всех типов:

setup
id | type     | value
1  | template | temp1
2  | template | temp2
3  | meta     | keywords
4  | meta     | description
5  | banner   | banner1.jpg
6  | banner   | banner2.jpg

И еще один похожий, но немного иной случай: таблица соответствий. Например, соответствия новостей и статей своим разделам.

Тут можем или создать две таблицы:

news_match                  articles_match 
id | news_id | section_id   id | article_id | section_id
1    ...       ...          1  | ...        | ...

Или, опять же, только одну:

table_match
id | type    | left_id | right_id 
1  | news    | ...     | ...
2  | article | ...     | ...

Напоминаю вопрос: что из этого, по вашему мнению, предпочтительней и почему. Что скажете?

_____________

Предпочтительно разделение по типам сущности, даже не особо вдаваясь в теорию реляционных СУБД и удобство маппинга данных в объект приложения, а хотя бы потому, что чем меньше записей в таблице, тем меньше времени нужно движку СУБД чтобы найти нужную, а также шире возможности по настройке индексов. Не надо бояться множества таблиц, на более-менее крупных проектах их обычно больше 100, для БД это как отдельные файлы (метафорически, но иногда и практически), ничего страшного. Об объединении можно думать, когда операция JOIN нескольких таблиц начинает занимать слишком много времени. В общем, преимуществ данного подхода можно насобирать гораздо больше, чем когда всё в одной куче.

тебе просто то надо почитать про нормальные формы бд.

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker