Just out of curiosity, how did you come to the decision for the DB design that you did?
It seems to me that it would make more sense to have:
A table 'projects' that has and id, an name, and a description.
A table 'classes' that has an id, a project id, a name, a description, and an example field.
A table 'functions' that has an id, a class id, a name, a description, and an example field.
A table parameters that has an id, a function id, a type, a name, a description, and an example field.
Then you can just correspond items together based off of their parents id since you appear to be focusing on the OO portion of PHP. I haven't looked at the system too long, but this stands out as a big question off the bat.
Thanks,
Ryan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just out of curiosity, how did you come to the decision for the DB design that you did?
It seems to me that it would make more sense to have:
A table 'projects' that has and id, an name, and a description.
A table 'classes' that has an id, a project id, a name, a description, and an example field.
A table 'functions' that has an id, a class id, a name, a description, and an example field.
A table parameters that has an id, a function id, a type, a name, a description, and an example field.
Then you can just correspond items together based off of their parents id since you appear to be focusing on the OO portion of PHP. I haven't looked at the system too long, but this stands out as a big question off the bat.
Thanks,
Ryan