Database, EAV, and Data Manipulation
Adobe Commerce uses a relational database (MySQL/MariaDB) with a hybrid model: flat tables for simple entities and EAV (Entity-Attribute-Value) for products, customers, and categories. EAV separates entity data into eav_entity, eav_attribute, eav_entity_type, and backend tables such as catalog_product_entity_varchar, _int, _decimal, _text, and _datetime. Attribute backend type determines which value table stores the data - a common exam trap: a select/multiselect/static attribute behaves differently, and static attributes are stored as columns on the main entity table, not in a value table.
Attribute properties include frontend_input, backend_type, source_model, backend_model, frontend_model, and is_global (scope). Scope determines whether values are stored globally, per website, or per store view, exposed via store_id in value tables.
Indexers flatten EAV data into index tables (for example catalog_product_index_price, catalogsearch_fulltext) so storefront queries stay fast. Indexing modes are update on save and update by schedule (MView changelogs). Understanding that a price change may not appear until reindex is a frequent scenario question.
Data manipulation should use repositories and collections (getCollection(), addAttributeToFilter, addFieldToFilter) rather than raw SQL, though Magento\Framework\App\ResourceConnection is available for direct queries. Always use parameter binding or quoteInto to prevent SQL injection.
Worked rule of thumb: To add a product attribute programmatically, use a data patch with EavSetupFactory and addAttribute(CatalogProduct::ENTITY, 'code', [...]), specifying type, input, backend, source, global, and required. If the question asks where the value is stored, map backend_type to the corresponding catalog_product_entity_* table.