well, your table structure is all wrong, something like this i think is what you need:
table users
userid (int, primary, autoincrement)
username (varchar)
whatever else
table categories
catid (int, primary, autoincrement)
name (varchar)
position (an int (or varchar) to sort by)
table items
itemid (int, primary, autoincrement)
userid (index)
categoryid (index)
name (varchar)
flash can do instigate the following requests?:
create new user
get user list
select user
get category list
get item list
update item
add item
delete item
each request needs to pass the relevant info:
create user
- posts to the php handler the user's name
- handler creates the user if they don't exist, and returns success or failure (perhaps a message)
- could have the same return as select user with the new user selected, perhaps
get user list
- posts to the php handler a request for a list
- handler returns a list of users (xml, I guess)
select user
- posts the requested user id
- script returns success or failure?
get category list
- posts request for categories
- returns an (xml?) list of categories
etc...
you figure out which tasks you want to be handled by the flash - ie you may want the user list to be predefined, and you already know which user (and their id) you have through another method. same perhaps with categories
figure out what needs to be posted to identify any single request (ie, an item delete request will require to know which user, and which category, as well as item id, if it is to verify that the delete request is valid for teh current user and that they are in the right category, or if you can safely assume correct user is requesting and they have the right category, you can just send itemid)
then make sure the php script can figure out what is being asked of it, query the sql to create/retrieve the information, and then format up a response that flash can use.
the data structure remains constant, and it is easy to just pull entries as needed and spit them out.
of course, if your user list and category list is static/predefines, you can probably manage without either of those tables, and instead use one table similar to the following:
table items
item_id (int, primary, autoincrement)
user_name (varchar)
category_name (varchar)
item_name (varchar)
then, you get teh user and category passed in the request, and use it to filter out the items for that user for that category (or to define when creating a new item entry)