Posting in the Magento forums has been disabled pending the implementation of a new and improved forum solution which should better serve the community.

For new questions please post at magento.stackexchange.com, the community-run support site for the Magento community. We will be providing updates on the new forum solution soon. For questions or concerns please email community@magento.com.

Magento Forum

Understanding catalog_category_entity_text table
 
jsperri
Sr. Member
 
Total Posts:  126
Joined:  2007-08-31
Fistufle
 

Hello,

I am trying to write a custom loader to move categories and products from an Oscommerce setup to Magento.
So far, I have figured out most of the tables and relations for the categories, I am just a bit confused with the catalog_category_entity_text table.

I more or less understand the table structure, which seems to be used to help locating a category node within the tree, each node being described
by its attributes all_children (121), path_in_store (122), children (123).

My question is, couldn’t this information be “calculated” from catalog_category_entity, since it contains parent/children relations ?
What is the exact use/function of this catalog_category_entity_text table ?

Thank you for your help,

 
Magento Community Magento Community
Magento Community
Magento Community
 
Moshe
Magento Team
 
Avatar
Total Posts:  1770
Joined:  2007-08-07
Los Angeles
 

The Catalog, Customer and Sales modules are using Entity-Attribute-Value model to store the data (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model)

It allows great flexibility that Magento uses for product attributes and future customizations with categories, customers and orders.

All the entity types are stored in `eav_entity_type` table.
All the attributes are in `eav_attribute` table.
These and few other tables define the data structure for these module’s entities.

Entity data is stored in header file and at least 5 additional tables that store the data by the type.
For example products:
`catalog_product_entity`: entity header table with system fields (all system attributes probably will migrate here)
`catalog_product_entity_datetime`: table containing datetime values of products
`catalog_product_entity_decimal`, `catalog_product_entity_int`, `catalog_product_entity_varchar`, `catalog_product_entity_text`: same as above, other data types

datetime, decimal, int and varchar values are indexed to be quickly found.

In same tables few entity types can be stored. For example in `sales_quote_entity*` tables are storing information about quotes, items, addresses, payments.

There is Mage_Eav module that provides an interface which allows to use these db structures without overhead in object models.
That means, if someone likes static database structure they will be able to create their own resource models that will utilize native database tables.
But even this is not needed because it is possible to move all the entity attributes into header table and then it will be equivalent to regular table usage without changing line of code.

 
Magento Community Magento Community
Magento Community
Magento Community
 
gamelodge
Sr. Member
 
Avatar
Total Posts:  89
Joined:  2007-08-31
Brisbane, Qld, Australia
 

Hi

Could i ask why your using the EAV model and not the Sparse column model.
i think exprssion engine use sthe sparse column model.

was there any reason for not doing magento this way.

i like what you guys have done.

 
Magento Community Magento Community
Magento Community
Magento Community
 
Moshe
Magento Team
 
Avatar
Total Posts:  1770
Joined:  2007-08-07
Los Angeles
 

@gamelodge: Our first priority was flexibility, and that’s also first priority of EAV model, so we’ve matched smile

Wikipedia article explains the idea behind it so I won’t get into details.

These are main reasons behind the decision:
1. Ability to easily add/remove attributes without changing database structure
2. Dynamic record length for entities, which plays nice for different types of products with different attributes.
3. All attributes are implicitly indexed, ergo can increase performance without use of index tables.

Thanks to the separation of abstract object model and resource model, if someone prefers traditional relational model - it is possible to create resource models that will employ it without changing much in application logic. Additional resource models can be done as separate modules. So we are not bound to EAV for specific implementations.

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top