What is the best way to implement additional fields?

Question

MySQL

I am writing "CMS" on laravel 5.2, for future projects, and there was a question about additional fields for added publications. Additional fields will have types: numeric, text, drop-down list, date, template, etc.
The idea of ​​implementation is this: Tables:

• publications - table of publications
  
• additional_fields - table with added fields
  
• pubication_fields- таблица публикаций в которой хранятся значения доп. полей публикации
  
• publication_extra - таблица публикаций в которой будут храниться статистические данные публикации (просмотры, кол. комментариев, рейтинг и т.д.)
  

Вопрос заключается в строении бд. Будет ли это лучшим выходом из ситуации? Вроде, сделал по правилам "нормализации"? Например, в DLE это сделано в колонке "xfields" с типом text, таблица с новостями, где хранятся все значения доп. полей, но мне кажется это не слишком хорошим выходом.
P.s. Пока все описывал, понял, что довольно глупый вопрос :)

Answer 1

P.s. Пока все описывал, понял, что довольно глупый вопрос :)

А я вот не понял почему глупый вопрос? Можете объяснить?

Answer 2

I am also studying this issue, and so far I see that the most optimal implementation option is like this (such as infoblocks in Bitrix or information systems in HostCMS).
We have the following tables:
1) The records themselves (id|...|category_id)
2) Categories (like id|parent_id|customfields_table)
3) A set of custom fields for the category (id|custom_1|custom_2|...)
4) Description of custom fields for the table of custom fields (custom_{id}|type|name|slug|...)
Something like this, everything is normalized and connected, in my example, sets of custom fields are tied to categories, as in JBZoo or in HostCMS, but in this In the same style, you can bind them to other entities, like infoblocks in Bitrix, but these infoblocks are also associated with categories (well, then the logic already depends on the tasks).
Are there any other considerations?
PS And the question is interesting and not at all stupid.

Answer 3

The main question is how often the table changes, how much extra is planned. fields. and to what extent do all rows have these fields?
Those. example:
if there is a field that 1 out of 1000 records has, then it makes sense to put it in a separate table.
The same fields as "date of creation", "author's number" and so on, it makes sense to store in the main table publications.
It may not be a completely normalized table, but it's more practical :)