PHP associative array to tree array

I assume the 3 deep array is only as an example and you want a generalized solution.
Furthermore, I assume this is homework? It looks like an exercise, not a real world problem.

For an array with x rows (0 to x-1), each a list of y (0 to y-1) elements, I would start creating arrays starting with the y-2 element to the beginning.
Maybe recursive, but a foreach is fine too. The end result should be what you want.

HTH,
Dan

I agree with Dan -- this is a highly theoretical-sounding problem because nobody does this sort of thing IRL.  So please help us understand the boundaries of the assignment a little more.  Do all of the "sub-arrays" in the initial state have the same count of elements?

Also, worthy of note... This is not an associative array problem.  PHP is a loosely typed language and these are numerically indexed arrays.   Maybe a trick question?

Yes i'm looking for a generalized solution and it's a real world problem (my problem) i'm developing an ecommerce site and items can have Attributes (none to many) and this attributes have options. Attributes example are: Size, Color, etc. and options of this attributes are (for example) XL, L, S, Red, Blue, Green...

I'have developed a system (sorry i write english very bad) so I got cartesian product of all Atributes/Options and an item can have Green color only in XL and Blue color only is S (depends stock) with the cartesian product i have saved items optios/attributes combinations as a serialized array of Idoptions valid for a determinate item.

Attributes
---------------
Id
Attributename


Options
-------------
Id
Idattribute
Optionname


Validcombinations
----------------------------
Id
Iditem
SerializedArrayOfValidOptionsForThisItem (no storing Idattributes, only Idoptions because from this Idoptions, i got Attribute field)

Now i want get the typical select form field:

Size
------
Color
-------
Etc

So, depend wich size you select from first option (My famous first value of my array example) y load via Ajax the valid Idoptions for the next element Color this case.

My first array was the Idoptions valid values for an item

                0 => array(1314,1317,1320),
                1 => array(1314,1317,1321),
                2 => array(1314,1318,1320),
                .....

Is there a better solution for store (MySql) valid option combinations (indeterminated number) of Attribtes and Options?

Thanks anyway for your previous answers!!!

Ahh, now I understand better, thanks for that explanation.

Anything you sell is identified by a stock-keeping-unit number ("sku" number).  Each sku identifies something that can be picked from inventory and shipped to a customer.  So a shirt is not a sku.  Nor is a red shirt a sku.  But a red shirt in size "s" might be a sku if you can send your employee into the warehouse with the instructions to "pick sku xxxxx" and they will come back with a red shirt in size small -- the thing that exactly satisfies the customer order.

If you further differentiate the red shirt (buttons, zippers) then the shirt->red->small is no longer a sku.  It would need to become two skus:
  shirt->red->small->buttons
  shirt->red->small->zippers

The inventory database table has two columns: sku and quantity.  As each item is picked for shipment to a customer, the quantity is reduced for that sku.  When the inventory reaches a lower threshold, you can reorder from your suppliers who delivers that sku to your warehouse.

The description associated with a sku is a row in the table of skus.  It would contain information about the sku in sufficient detail to unambiguously identify the exact product.  Each column would be named in a way that denotes a feature and the column would contain a value, if that value applied to the sku, or NULL if that value did not apply.

In the online bookstore, pioneered by Amazon.com, the sku is the ISBN, which uniquely denotes a product, encompassing the book in its embodiment for sale.  Different covers (hard, soft) have different skus, even if they are the same book.  This results in a "flat" and simple design that is easy to understand, maintain, and sell.

Does that help to make sense of the design pattern?

If I understand the request correctly - what is required is a structure that allows for the easy selection of valid attributes / options based on previous selections.

The SKU will uniquely identify an item but not give its attributes / options in other words it will uniquely define a size and a colour (say) but not tell you what all the sizes and colours are for shirts.

When client selects item shirt - you want the next attribute box to be populated with Sizes
When they select a Size you want the next box populated with colours

For this you need a structure that has the item id as the root followed by the attributes and options that can be easily accessed given this item id.

Is this correct?

SKU will uniquely identify an item but not give its attributes / options

Erm.  The SKU is for inventory.  The items for sale typically have tables of attributes associated with them.  Pants have waist sizes, shirts have sleeve lengths, both have color, etc.  This is part of the item definition, and it's only generalized within a given item.  Sleeve length or collar style do not make sense when you're talking about books or pants.  But SKUs apply to all items.  

Online shopping sites do not present product detail information in an ordered cascade; they present this information as a collection of selections and allow the client to filter according to preference.  You can see this in action at LandsEnd.com, if you look for Mens' Shirts. The selections are "Dress shirts, Casual shirts," etc.  Then the selections give a variety of colors and collars, sizes, styles, fits, materials, etc.  You don't have to choose the size before you choose the color; it's all right there at your fingertips.

Having said that, though, the education necessary to understand the design of online shopping sites is typically a masters degree in marketing, and it's not something anyone can get from an online forum like E-E.  We're pretty good at answering technical questions, not so much when it comes to broad, opinionated design questions, and any answer we give about generalized eCommerce design needs to be tempered by an understanding of all of the moving parts associated with eCommerce.  It's a little bit broader than rearranging a matrix into a tree :-)

Erm.  The SKU is for inventory.

I am aware of what SKU's are - you misread my post. I was pointing out that the SKU does not carry the global set of attributes / options that are part of the parent item. An sku for a shirt-red-small does not tell you what other colours and sizes the shirts come in.

My understanding of the author's question was that he was looking for a way to present the set of attributes and options for an item back to the client in a format that could be easily used to make selections of said attributes and options.

I think a sku for a shirt would carry all of the options available for an equivalent shirt.   Some might be empty.  Whether you put these options on the client browser, perhaps disabled for the options that were out of inventory, is a design and business question, not something about arranging data in PHP arrays.  The shirt sku would be different from a sku for a book or a dishwasher, where the options would be different.  This is a narrow question, but it seems to be about a broad subject.  In eCommerce designs you don't make a tree of valid options - you make a flat file of products you can sell.  The flat file only looks like a tree if the web site publisher wants to lead you through a selection process in order to glean information about your preferences as you shop.  It's valuable marketing information to know how the client navigates the site, but it does not change what is in inventory or available for sale.

The flat file only looks like a tree if the web site publisher wants to lead you through a selection process in order to glean information about your preferences as you shop

Isn't that what this question is about?