I have evaluated umbraco and believe it is a good cms for my project. But there is something really bugging me. When I open the backoffice all the child nodes are displayed for a certain node. What if a child node has millions of nodes. Will all these nodes load in the backoffice? This is the only problem I have with umbraco as my next project will require loading tens of thousand of nodes per day.
This is not a question for SO, you should really ask it on the http://our.umbraco.org site.
However ... You need to look at your architecture - how you plan to implement your project and also how users are going to use the backoffice too. Loading purchase orders, sales orders etc as nodes in the CMS does not make a great deal of sense. After all, Umbraco is a CMS not an ecommerce solution. And navigating 1000s of nodes would be horrible for a backoffice user.
Generally, you should restrict nodes to being related specifically to content. If it isn't content then it shouldn't be a node. There are exceptions, e.g. you could create content categories and date folders as nodes. These are not strictly content but impact how content is displayed.
Products displayed on a site is an interesting one because you could argue that a product is content. But then it depends on how many products you are listing. If you have a catalogue of 10000 product SKUs, yes Umbraco would probably handle it but is this the best use of Umbraco?
The alternative to creating data in nodes is to have separate db tables that hold the relevant data (in this case orders) and then have a custom section within the CMS that provides access to listing/detail/edit screens. This approach is probably much more appropriate when dealing with large volumes of data as you are not putting the load on Umbraco - a custom section essentially by-passes Umbraco and allows you to access data directly from the database in whichever implementation you like (MVC/Web forms).
Finally, I should point out that there are already several ecommerce packages available that will do this for you. See teaCommerce and uCommerce
Updated at 03/2015:
I've just completed an Umbraco ecommerce project using uWebshop (an open-source option). It does create products as nodes and I thought I should probably update this answer. In this circumstance the shop had a very small catalogue (< 50 SKUs) and so having products as nodes didn't pose an massive issue. I could see however that managing a much large catalogue (e.g. 500+) in this manner would become extremely unwieldy.
Related
In working with Magento's EAV system, I have developed a PHP-based tool which will assemble the tables' data back into a tabular format as well as identify "holes" in the attributes between or across products. It works with both the product and category system, and allows determining if an attribute has NOT been inserted into a particular product, or if data is consistent across stores, or stores which are inconsistent - things that are not easy through normal SQL queries and which might be tough to program with Magento native coding.
I plan to post a link to this via github and here when complete.
My question is, are there other platforms or system which make use of EAV? I would like to make my application as system-agnostic as possible. Thanks.
I need to improve indexing times, specifically "Product Prices".
I would like to know if I need to actually delete a store view in order to improve indexing performance, or would it be enough to disable it. I'm talking about store views in different websites in a multi-site Magento installation.
How much does an extra store view affect performance with tens of thousands of products, each with different prices per store view (the other attributes are the same)?
Thank you.
Magento does not check if store view is disabled. If you will not index this data you must delete the store view, create your own indexer or rewrite magento's indexing behavior.
we have 250k products and we want to create more than 200 different site(multi site) all stores will have same products but different domain and different design. Magento multi site function is good for us but you need to match every product and every site so that means 50m(min) record for tables like "catalog_product_website"(and some other tables) and also flat catalog and indexing will be a real problem.
if we use store and store view than userbase will be same and also flat catalog will be problem.
So my question, is there any way to make all these stores work like single store? Or is there any way to make it work with nice performance?
The short answer is no.
While Magento is built for multi-site applications, I don't think it's suited to running 200+ stores with 250,000 products.
At that size, I'd say contact Magento regarding Magento Enterprise to see what they have to say. Oh, and be prepared to pay the $15,000/Server/Year price.
Most of you coders most likely already have the habit of working on different platforms (development-staging-production). In the company I work with they also have these different platforms with a Magento enterprise edition (v1.9.0.0) instance deployed.
About 2 months ago our team took a database backup of the production version to start working from (rather large development project about the content (product images, descriptions, ...) and automatic product loading.
Currently all the modifications have been deployed on the staging platform, containing order information of orders that have been placed two months ago at latest.
After buying a (badly coded and full of bugs) extension for exporting and importing orders (including order information, quotes, shipping info and customer info) which does not work properly I had decided to just copy all the following tables from the production site:
All tables starting with customer_
All tables starting with s_
All tables starting with sales_
I imported them on my development platform (just to try it out and it works! :O
All order, shipping, credit-memo and customer information is maintained and seem to be fully working and correct.
Here comes the actual question:
Will there be a chance of possible conflict with something order/customer-related in the future by doing this? As far as I know orders only carry relations to customers and customer addresses and not to actually products (at least I think they are linked by SKU and not by product entity_id like most things in magento)
This is proven by the fact that if you remove all products from your magento instance, all the order and customer information is maintained and fully working.
Edit: This actually worked ;)
This is probably a bit late but I have come across this situation several times recently and this is an excellent question and it's important to be aware of it to avoid future problems with the customer/sales relationship.
At the time of writing the most current Magento version is 1.7.0.2 and yes, the habit of working with a production and development site is likely, so the transferring of new sales and customer during the development is an important step to take and shouldn't require extensions if one has even little experience with the DB, so here it goes:
It is correct that the transferring of the customer_ and sales_ tables will transfer all the data correctly and safely.
Thereafter, one MUST only update the eav_entity_store table's increment_last_id column for each row.
Doing the last step above avoids that the new orders, invoices, shipping or creditmemo's ignore the new ID's and assures that the new orders start from where the transferred orders left off.
It may be a bit confusing, but its a very easy step. This Article explains it more in detail in case.
There's this script:
https://github.com/iateadonut/magento_copy_customer
It grabs a customer and all his orders through the single command:
$mg->copy_customer(1234);
if 1234 is the customer_entity.entity_id - You can take a look in the source code to see how the table restraints were queried to make sure all rows were grabbed.
You are approaching this the wrong way around. If you have EE , then it bundles content staging procedures and you should use that for your content changing.
And yes it most certainly can cause issues, as all your relations with other order related content like sent invoices, all objects attributes might just get new entity_id 's and this will eventually end in a mess along your road somewhere.
If you add attribute sets and attributes to a large installation it's always recommended to implement those as extension setup routines so you can move your codebase and all changes are automatically populated to whatever database you might connect in the future.
I am planning a high performance e-commerce project in asp.net and need help in selecting the optimal data retrieval model for the product catalog.
Some details,
products in 10-20 categories
1000-5000 products in every category
products listed with name, price, brand and image, 15-40 on every page
products needs to be listed without table-tags
product info in 2-4 tables that will be joined together (product images not stored in db)
webserver and sql database on different hardware
ms sql 2005 on shared db-server (pretty bad performance to start with...)
enable users to search products combining different criteria such as pricerange, brand, with/without image.
My questions are,
what technique shall I use to retrieve the products?
what technique shall I use to present the products?
what cache strategy do you recomend?
how do I solve filtering, sortering, pageing in the most efficient way?
do you have any recomendations for more reading on this subject?
Thanks in advance!
Let the SQL server retrive the data.
With fairly good indexing the SQL server should be able to cope.
in SQL 2005 you can do paging in results, that way you have less data to shuffle back and forth.
I think you will end up with a lot of text searching. Give a try for either lucene or Solr ( http server on top of lucene). CNET developed solr for their product catalog search.
Have you thought about looking at an existing shopping cart platform that allows you to purchase the source code?
I've used www.aspdotnetstorefront.com
They have lots of examples of major e-commerce stores running on this platform. I built www.ElegantAppliance.com on this platform. Several thousand products, over 100 categories/sub-categories.
Make sure your database design is normalised as much as possible - use lookup tables where necessary to make sure you are not repeating data unnecessarily.
Store your images on the server filesystem and store a relative (not full) path reference to them in the database.
Use stored procedures for as much as possible, and always retrieve the least amount of data as you can from the server to help with memory and network traffic efficiencies.
Don't bother with caching, your database should be fast enough to produce results immediately, and if not, make it faster.