[eluser]rideearthtom[/eluser]
Answers:
1. Each child site represents one or more products. Products will have certain common properties, for example price, which need to be stored in the master DB, but each product will also have numerous unique properties. Think of the 'product' as anything that can have a value attached and purchased - it might be a set of services, a download-access area, a tangible object, a visit from a professional, etc. The user-account interface and functionality for each child site will also need to be unique, except for the registration/authentication part. Hence the difficulty in deciding how to abstract the data model and where to store what.
2. Yes - for example, the user is given a login/password by the system admin, which is stored in the central db, and he/she can then use these credentials to login to any of the child sites and 'buy' the product that it offers. Likewise, a registration on any child site can be reused on any of the other child sites, though in reality this is an unlikely scenario, but the admin needs all of the registered users, their details and their purchases available in one place i.e. the admin back-end of the central app.
3. This is still an outstanding question I have with the client. I am sure that hosting all of the sites on a single server makes the most sense as cross-site DB calls can be executed securely. However, just in case, I'm thinking of the other scenario, where this functionality would be exposed without any direct DB access.
4. I'm not tied to any particular style of implementation, but as this is a prototype project for the client I guess that AJAX isn't a necessity (unless it is, if you get my drift!).
Cheers!
