@ACID: well, yes, ModeShape is ACID; However, you also need to take into account that there are other systems needing to get get access to data, and therefore you need a connector that can support that ACID. With RDBMs this is easy as every connector has it, with JCR its quite hard if not possible. Think about: you will use the system for 5-7 years on your estimate. You will need third party tools on some occassions and SQL and RDBMs are proved for data storage and integrity enforcement since the 1970's. Meaning you use an RDBMs also doesnt mean you need to connect to it via different paths, as modeshapes federation can actually feed you that data via its federation.
Of course you can store all in ModeShape - but I still wouldn't suggest this.
@5: you mix up the way how to store something vs. how to deliver it cost effectifely and scalable! Imagine an average visitor sees 5 pages with 100 product images in common. Why deliver that 100 requests from your own server, hitting your bandwith and drive latency while you can have it all for nearly no cost from e.g.: aws cloud front (only first request goes to your server for each image / caching cycle - rest ist delivered from their network) ? This IMHO is a no brainer, as if you have 1 000 visitors in parallel you'll need to server 100 000 images from your server. Give every one 100 kb and your at a sum of 10 000 MB for that visitors in parallel. And now compare that to http://aws.amazon.com/cloudfront/#common-use-cases (look at the media distribution use case!) and the prices they will charge and compare that to the sum of servers and hosting you'll need instead...
@design-model:
I see some design flaws in there:
ecomorganiztion/products/product1/skus/ (child nodes are actual sku items depending on whatever attributes this product has)
/ecomorganiztion/products/product1/attributes/size (child nodes, stores the actual size values for this product)
/ecomorganiztion/products/product1/attributes/color
/ecomorganiztion/products/product1/attributes/pattern
this might put you in truble. Each item is not "one", but usually contains of "2" different sets.
1st: Data you *require*: this has to be enforced! - Talking about ID, Manufacturer, Price, Taxvalue etc. etc.
2nd: Data you *want*: this is the way to enhance it on the page, info for the customer, nice to know etc.
Your way to store attributes out of the item itself will lead to stale data and chaos after some time as you need to understand that invalid data will eventually get inserted - no matter what you do, believe me! You need to make sure you enforce an fixed attribute set on #1; You can achive this with custom node type definitions however and storing the data within the item itself!
/ecomorganiztion/products/product1/images/img1.jpg
/ecomorganiztion/products/product1/video/vid1.mkv
Well, if you use federation to store it outside it might work. If you instead store it in the same workspace: bad bad idea. Think about backup and the sizes your workspace will reach. A video easily has 100MB, now you'll have 2500 products in the DB (half of max), meaning you store about 250 GB data only on video.... and now in year 5 you have 15'000 items in workspace (each year 3000 items exchanged) and your video size is grown to 250MB at average (hey, its 2018 by now!) - you now have 3 TB 750 GB.... only on video, stored along your items. Sure this is an good idea?
/ecomorganiztion/customers/customer1
/ecomorganiztion/customers/customer1/order11(stores path to products)
/ecomorganiztion/customers/customer1/order11/history (stores change history for the order)
/ecomorganiztion/customers/customer1/order11/comments (order comments)
This part will *not* work!
You cant just store the path to the products for orders! What if a costumer buys item A for $ 5.00, and you change the price for it to $ 5.50 the next day? What if you change the product description a year later and need to reprint that invoice receipt?
You need to understand that the lines in orders and receipts may *NEVER* *EVER* change after they are created - legally even the ordering of the lines is usually important. So you need to put all the required data in and store it there "forever" - enhanced with even more data, depending on the area of legal interest.
All over I think you might want to get the source code of magento or any other big open source ecommerce solution to get a grasp the the requirements of the data modeling. For example look the the ER schema of Oxid, a smaller e comerce app: http://docu.oxid-esales.com/CE/dbdocumentation/OXID_eShop_CE_4.3.0_26948_DB_schema.png and after that follow the magento schema (but not unless you understand why nobody really wants an EAV way of modelling things http://stackoverflow.com/questions/4066463/should-i-use-eav-model ): http://www.magentocommerce.com/wiki/2_-_magento_concepts_and_architecture/magento_database_diagram
Best,
KB
PS: you now also might understand why a good part should be in an RDBMs and not only pure JCR