Many properties in one infoblock. What is the best way to design a website structure?

Question

1C-Bitrix

There are already more than 3 thousand properties in the infoblock of the catalog and many more new ones need to be added. At the current stage, there are already problems with adding and saving. What is the best way to design the site structure to get rid of this problem? There are many tips on the Internet about dividing categories into infoblocks, but the problem is in the bitrix:catalog* component. In fact, the entire online store is tied to it and it supports only one infoblock. You can create sections manually, but a lot of components are tied to this component. I saw a solution through Highload blocks, but as I understand it, for this you need to rewrite something for yourself, because they simply store information and it’s impossible to simply implement fields through them, as I understand it. How to be in this situation, divide infoblocks into categories and manually make crutches?

Answer 1

I will immediately note the wrong vision of Bitrix:

the problem is in the bitrix:catalog* component. In fact, the entire online store is tied to it and it supports only one infoblock

a standard component is a controller that shows the possibilities of working with the Bitrix API (modules).
minus standard components: they are made for different tasks, i.e. there are many parameters, each parameter is the amount of data and processing. the resulting data array contains a lot of unnecessary information.

You can create sections manually, but a lot of components are tied to this component.

Components are tied when they are complex. those. one component calls another. Nothing prevents you from calling the components separately.

Highload blocks, but as I understand, for this you need to rewrite something for yourself, because they simply store information and you can’t simply implement fields through them

A highload block is a separate table in the database and linking them to infoblocks is not a problem, the infoblock has a reference field that shows how you can link it, but you don’t have to use it, you can create your own field, or it’s easier to write the connection processing in the component.
Infoblocks are best used when there is a need to use standard infoblock fields or functionality tied to them, for example, a sales catalog module (namely, a module), if a minimum of standard fields is used, and the entity is not processed, but only tied somewhere, then it is easier to use HighLoadBlock t .to. they get from basis one request.

making crutches by hand?

when you make crutches, as a result, the site processes the standard functionality (including the ones that are not needed in this solution) and your crutches on top, which leads to a heavy load and sometimes even to the "Bitrix-g ****" solution, so that this does not happen, it is enough to write your own components that are narrowly configured and process only the necessary information using the Bitrix API.
The answer to the question "How best to design the structure of the site":
first you need to describe in the technical specification all the functionality of the site, describe the links, and then think about where it is better to throw this or that field. 3000 properties, this is a dump, in any case, there is a need to scatter, even just to put things in order and make editing easier.
If the traffic of the store is more than 1000 per day, I recommend writing your own components, on your own components you can achieve and maintain a higher speed than on standard ones.

Answer 2

Bitrix does not support all non-standard solutions, and here experts come to the rescue. Perhaps your problem is not that the component or server cannot process your thousands of properties, but that you do not use these properties correctly, you misunderstand something.
The fact that you can scatter properties over infoblocks is also an option, again you need to know your "kitchen" whether this is necessary and Bitrix supports it, for example, bitrix:catalog.main component, which uses bitrix:catalog.
Highload blocks are fast, the infoblock property can be linked to Highload blocks as a link to the Directory. Or write your own functionality.

making crutches by hand

- not crutches, but your own solution to the problem))