Quote:
Originally posted by JaceXXX@Mar 18 2005, 06:39 PM
part 1
i need a normal admin done.....i have a site that has about 5 pages full of cars...each page is called new.php, classic.php, used.php etc...and I need a backend for the site that allows my client to enter in a car, select what section (i.e. New Cars) and what options are available on that car, and it adds the car to the site with all the options specified and in the section specified
part 2
I need a master admin done for the site that allows the master user to go in and create the options for the normal admin to choose when adding new cars
so, the master admin creates the fields and options for the normal user to select when adding cars
**********************************
this is all in my head what needs done
i think i found someone though...we will see
|
Cool that you may have found someone...
Now, just to clarify what I meant by more detail:
you have pages full of cars as you say. Are you selling them ? Just showing them off ? This would matter to whoever designed the database...
If you are selling them then you probably want price for example.
You say the normal admin guy "adds a car".. That can mean various things depeending on the context. It might mean just pointing to an image or some such or it might mean that the normal admin selects the various manufacturers/models/etc that are set up.
Your master admin you have defined as "the options". What do you consider options ? In my mind, options on a car are A/C, CD Player, Sunroof , all that stuff and I assume you mean the same. But if those are the options then where is the main car defined ?
Now, I know a little about cars so I could off the top of my head design a little database that probably would do everything that you want to do. But, another programmer might not know anything about cars and is dependent on you (the client) to provide the definition of what the data being stored will be.
The definition of the database is key in something like this and is why some of us spend long times in the design phase of any project including the ones that the client thinks is "quick and easy".
In this case, I would go after this with several tables in a database:
1. Manufacturers a unique id and name for any manufacturers that you may want to carry
2. Models a ubique id, a manufacturers id and a name for any models.. The manufacturers id provides the relation between model and manufacturer
3. Options table - this would be a vertically positioned table that simply had a unique id and a name for each option you might want to check off
4. A "Conditions" table (could be hard coded to poor, fair, good, etc but would be batter if it was table driven)
5. A Categories table (again could be hardcoded to New, Used, Vintage but again would offer more flexibility if table driven)
6. (Finally) The Car table. This would contain the various information for each car you would want to show so it might look like this:
Unique id
Manufacturer id
Model Id
year
price
conditionid
imagename
(possibly a location field if you are selling stuff from various cities)
(possibly coost and vin number fields etc if you want to track)
and the last table I see in a quick view would be the car-options table. This would be a vertically positioned table that would consists of a unique id, a car id and an option id and would allow for multiple records for each car record.
Now, my assumptions in this were that you are trying to sell cars, that you might want to easily add more categories later (muscle cars, antique, foreign, etc etc etc) and that you would want to be able to just add the category and have the proggy create the new page(s)
I would also assume that you would want to control the number of cars per page and that you may or may not want to display pictures of the cars.
As I said, this assessment was based on your description and is the kind of information someone really needs before they can make any kind of realistic quote on something.
Just imho of course.