Why does Magetno have three flat tables? What specifically three (not two, not four)
There's three for catalog_category_flat
catalog_category_flat_store_1
catalog_category_flat_store_2
catalog_category_flat_store_3
and three for catalog_product_flat
catalog_product_flat_1
catalog_product_flat_2
catalog_product_flat_3
Why?
Magento's structure is Website > Store > Store View
So those stores that Jeeten is talking about are actually Store Views. You can see them in admin under System > Manage stores or in the database in table core_store.
To clarify what a few other the other commenters/answerers are saying.
Magento can, famously, host multiple "stores" in a single installation. It does this by having different store views. Many Magento product and category features are configurable per store view. In a non-flat Magento system, this is achieved via the EAV tables and storing multiple values indexed by different store IDs (oversimplification)
So, this means Magento needs a single flat table for each store view. In your installation (and with the sample data) this means three tables since there's three store views.
Related
We've got 2 magento stores configured, A and B:
Store B only shows categories and products below the catgory CAT2.
Now, when searching on store B's front-end, products from categories of store A come up. How can I avoid that? I'd like to cleanly separate products assigned to store A from those assigned to store B as store B is a specialized product segment presented with another company.
Any idea how to do this?
we finally set up the second store as a different website, this way we can assign products to either one or the other in the website section of the product, and search results adapt accordingly.
I've troubles to figure out how to change the prices of a product in the magento DB.
I tryed to change the prices in the catalog_product_index_price table but the price doesn't change.
There is a website here that explains it in more detail, but the short answer is that you need to change the price in the catalog_product_entity_decimal table and then reindex Product Prices in the backend (and potentially Product Flat Data as well)
Magento uses variety of indexing and caching methods that make simply changing the value directly in the database not a good idea.
If you look, you can see the prices are also defined in the Price Index tables:
catalog_product_index_price_idx
And also the flat tables (if you use them):
catalog_product_flat_1 (number 1 depends on store)
If you're trying to mass update prices, I recommend either using a tool such as Magmi or the built in Magento import methods to update prices. Directly modifying the database is generally not a good idea with Magento, given it's complex database structure.
I'm trying to develop a Magento plugin which involves using coupons. Apparently after looking around I found a source that mentions use of a 'salesrule' table for coupons. However when I looked at my database i couldn't find it. However I did find 3 tables that had mention 'coupon' called 'coupon_aggregated', 'coupon_aggregated_order', and 'coupon_aggregated_updated'.
I just wanted to know what is the difference between the 3 tables so I can start using them? I am on the latest version of Magento.
The table you're looking for is indeed named
salesrule
There's also a table named salesrule_coupon, which contains specific coupon codes linked back to the main salesrule definition.
If your database is missing this table, something bad has happened to your system. Go to
Promotions -> Shopping Cart Price Rules
and create a new coupon code with a distinct title. Then dump your database content and search for the text of your distinct title. That will let you know which table your system is storing salesrules in.
The tables you mentioned above are aggregate data tables used for reporting only.
In my Magento store I currently have Flat Catalog Product turned Off because it breaks some custom code I have on my site.
However, I am have a single instance where it would greatly help me to have the collection use the flat table as opposed to the EAV tables.
Is there a way I can tell the product collection to use the flat tables as opposed to the EAV tables in my code?
This is a great opportunity to fix your custom code :) In the default system, flat catalog is either turned on or off, not with any level of granularity. Depending on the nature of the hack that breaks the flat catalog, it may be possible to avoid that issue and just it turned on globally.
Perhaps more detail into the issue that caused you to leave it turned off?
We have a website with 2 store views: FR and EN. For some products after import catalog_product_flat for EN store view is not refreshed. In EAV tables everything is fine. Data re-index should truncate this flat table and fill it with updated data. Somehow it doesn't work for some items.
Did anyone of you had a similar problem? I'd appreciate for any clues or advices on this topic.
EDIT
I have made further checks and I was wrong about EAV tables. It turns out that catalog_product_entity_varchar is consistent with catalog_product_flat. So flat table has the same data as EAV table but in the Admin Panel values are wrong. For EN store view they are the same as default values, only for some products (magic? ;)). On my local PC I didn't encounter such issue. This is only on our production environment. As far as I know we do not use any DB replication (which could be the issue here).
EAV database model is used by Magento for easy upgrade and development as this model gives more flexibility to play with data and attributes.
When flat catalog is enabled in Magento then all the above product attributes (id, name, price) are kept in one table named like catalog_product_flat. Then Magento fetches product data from the flat table rather than joining all the other smaller tables.
There are two types of Flat Catalog:
1) Flat Catalog Product
2) Flat Catalog Category
Flat Categories are recommended for any Magento installation for improved performance.
Flat Products is designed and recommended for catalogs that have over 1000 SKU’s.
Enable Flat Catalog Category:
Go to Admin Panel->System->Cache Management->Rebuild Flat Catalog Category
Go to Admin Panel->System->Configuration->Catalog->Frontend->Use Flat Catalog Category = Yes
Enable Flat Catalog Product:
Go to Admin Panel->System->Cache Management->Rebuild Flat Catalog Product
Go to Admin Panel->System->Configuration->Catalog->Frontend->Use Flat Catalog Product = Yes
Remember that, initially the selection list of
Admin Panel->System->Configuration->Catalog->Frontend->Use Flat Catalog Product
OR,
Admin Panel->System->Configuration->Catalog->Frontend->Use Flat Catalog Product
is non-editable. You have to rebuild Flat Catalog from Cache Management. Only then the selection list becomes editable.
Make sure that while importing of the Catalog Products, the required attributes of the products are provided with correct values in the import file. If this is not done properly, then Data re-index may not function correctly.
Also before re-indexing, it is always advisable & wise to clear the cache from the "Cache Management" & from the "cache" folder of your Magento installation directory.
Hope it helps.
I was wrong about what's wrong. And everything is OK with database. The problem was an order of attributes that are retrieved from DB.
In Mage_Eav_Model_Entity_Abstract we can find:
$selects = array();
foreach ($this->getAttributesByTable() as $table=>$attributes) {
$selects[] = $this->_getLoadAttributesSelect($object, $table);
}
if (!empty($selects)) {
$values = $this->_getReadAdapter()->fetchAll(implode(' UNION ', $selects));
foreach ($values as $valueRow) {
$this->_setAttribteValue($object, $valueRow);
}
}
Line implode(' UNION ', $selects) concatenates all select statements. But there is no ORDER BY, so data can be retrieved in random order. As a matter of fact, for some of the products it is like this. That select takes values of attributes for store view 0 (always) and selected store view (current one).
Array $values contains of arrays with attributes properties. Order does matter here, because if attribute (for example 'name') for store view e.g. 1 will be proceed before one for store view 0, then it will be overwritten.
Solution is to add ORDER BY clause to the $selects or sort $values array.