What is the best way to organize the structure of a category object that has large text?

Question

symfony

Please don't kick too hard for a noob question. The question is not specific to Symfony, but I work with it and Doctrine.
I need to make categories on the site - in fact, this is a site menu consisting of 50-60 items. The category has text - on average, the text size is about 6kb. The menu is present on all pages (well, as usual on sites), but the text is displayed only for the current category, and not all at once. It turns out that the rest of the categories will simply consume server resources, and on shared hosting they are not unlimited.
I'm not an experienced programmer, so I'm asking for advice. What is the best way to organize the category object:
- leave the category just a field with text?
- or take the text into a separate object and embed it in a category?
Perhaps due to the use of doctrine in Symfony, the resource consumption will be greater than in native PDO, and is it still better to use a nested object with text? I ask about this because. Symfony has the ability to use "lazy loading". And if I understand correctly, then when using it, and categories with embedded objects, not all texts of 60 categories will be loaded, but only the one that will be accessed, which will reduce resource consumption.
In general, tell me, how is it usually done? The fact is that I also want to make tags that will definitely be embedded objects in the category (described above) and other objects (for example, articles, pictures). Tags also need to add text for SEO optimization, which will also be shown on the page only if the specified tag is active (selected). And it turns out that the category will have its own text, and the texts of all the tags that are assigned to the category. In this case, do you need to embed the text of the tags as a separate object?
Thanks for the help!

Answer 1

There is no need to take out any text or other information (preview, metadata, etc.). all information relating to one category should be together, in one line of the database. if this data did not belong to a specific category, but to a group or some other, then structuring could be considered, but if the data is unique, then it is not worth splitting it. As for requests, it is functionally necessary to spread - just the output of categories, possibly with a preview; displaying the category itself on a separate page with a description and other content;
Of course, these are different queries to the database and not a complete list, the main ones. Let me remind you that the categories themselves have a tree representation (usually so). Therefore, we do not forget about the parents and the implementation is better where to peep the thread. something like this.