Designing the structure of 1C-Bitrix information blocks

iblock Structure Design for 1C-Bitrix

An iblock is the central unit of content storage in Bitrix. A poorly designed iblock becomes a problem within a year: filters stop working, 1C imports corrupt data, and queries against b_iblock_element_property generate full table scans. A well-designed iblock runs without structural changes for 5–7 years.

Data Types and Choosing a Property Type

Every iblock property has a type, and this decision cannot be changed without a data migration. Core types and their purposes:

• String — text values with no repetition. Not suitable for reference data (brand, country, material) because it is not indexed by the facet and creates duplicates in b_iblock_element_property.
• Number — for numeric values used in range filters (price, weight, power).
• List — for a fixed set of values (statuses, size categories). Values are stored in b_iblock_property_enum.
• Reference (HL-block) — for dynamic reference tables with many values (brands, countries, tags). Stores an INT key instead of text, indexed by the facet.
• File — images and documents. For product catalogs, additional images are best stored here rather than in DETAIL_PICTURE and PREVIEW_PICTURE when there are more than two.
• Element link — a relationship between iblock elements. Used for related products, accessories, and kits.

iblock Type Structure

An iblock type is a grouping with no technical significance, but critical for manageability. The rule: one iblock type = one data domain. "Catalog", "Articles", "Banners", "References" — correct grouping. "Site" as the only type for everything — an anti-pattern.

For an online store, the typical type structure:

• catalog — catalog and trade offer iblocks
• content — news, articles, FAQ
• references — reference tables (used as source for "List" type properties, if not HL-blocks)
• landing — landing page blocks, banners

iblock Sections: Hierarchy Depth

Sections (b_iblock_section) are stored in Bitrix's native tree. A practical limitation: nesting deeper than 5–6 levels creates problems with breadcrumbs, SEF URLs, and navigation. If the business requires deeper hierarchy (e.g., spare parts: manufacturer → model → series → assembly → part) — replacing hierarchy with properties and filter-based navigation is worth considering.

Multiple Properties and Performance

A multiple property stores several values in b_iblock_element_property — one row per value. 10,000 elements × a property with 5 values = 50,000 rows in the table for that single property alone. With multiple reference properties the facet index handles them correctly, but the rebuild load is higher.

Rule: if a property is rarely filled (only 10% of elements have a value) — empty records are not stored, which reduces table volume. If a property is filled for all elements and changes rarely — consider moving it to a separate HL table via DataManager.

Case Study: iblock Design for a Real Estate Aggregator

A platform for property sale and rental listings. Initial decision: one "Properties" iblock with 40 properties, including string fields for address, district, and metro station.

Problems after 8 months:

• Metro station filtering worked as a text search (LIKE), not via an index
• Duplicate values: "m. Arbatskaya", "Arbatskaya", "arbatskaya" — three separate records
• Radius search from a metro station was impossible without geographic coordinates

Redesigned schema:

• catalog type: "Properties" iblock + "Residential Complexes" iblock
• HL-block hl_metro with fields: UF_NAME, UF_LINE, UF_LAT, UF_LON — 342 records instead of text values
• HL-block hl_district — districts linked to cities
• Properties "Area", "Floor", "Floors" — type "Number" for range filtering
• Property "Metro" — reference (HL), multiple (several stations)

After restructuring, the facet index: builds in 3 minutes for 85,000 properties, metro and type filter — 0.15 seconds.

What iblock Structure Design Includes

• Defining the list of iblocks and iblock types
• Designing the property schema with type selection
• Decisions on HL-blocks for reference properties
• Designing the section hierarchy
• Identifying properties that participate in the facet index
• Documentation: schema in table format for each iblock
• Estimating data volume and projecting load on b_iblock_element_property

Timeline: from 3 to 10 working days depending on the number of iblocks and the complexity of the subject domain.