I just hope u distinguish the IDs. Like not just ID as coloumn name in each table, but AuthID or RevID, or ProdID and use those as the column names ith the foriegn and primary keys.OK, now the part of every database that scares the hell out of me - the archtecture. How do we plan on doing this?
(It is said a good programmer looks both ways before crossing a one way street.)Code:Product - id - manufacturer [link: Manufacturer.id] - model - street price - power input/output - T/S spec (where applicable) - Efficiency (where applicable) - author id [link: author.id] - type id [link: type.id] Type - id - kind {subwoofer, amp, comp set, coax, mid, tweeter, enclosure, etc} Reviews - id - item reviewed (product, manufacturer, other review, author, or picture) - item type (review brand X subs in general, or brand Y comps in general! if applicable) - item id [link: item reviewed.item id] (if applicable) - date posted - review - author id [link: author.id] pictures - id - item reviewed (product, manufacturer, other review, author, or picture) - item id [link: item reviewed.item id] - picture - author id [link: author.id] Authors - id - username - join date - posts
Either way can be done, but we need this figured out before we can get to the all important part of putting data into and getting data out of it.
It helps when linking, tahts all.Well, I had a pretty clear diagram of the layout before I started, however now that the structure is pretty much finished those diagrams are about as useful as a 14th century map of Africa. =)
The IDs stayed "id". As I've been saying this kind of thing isn't exactly a livelyhood, more a hobby I grew out of. That said, what are you talking about? Foreign key? I used "id" because it's universal. I can set what table to get a specific id from. Otherwise, it's just another variable I have to softcode. Yeah, I could do it, but it's just more effort that I have yet to find necessary.
it's a CMS - content management system.Finished product?!? I just started today. I'm going to see if I can accomplish basic input/output today. So far so good, I guess.
EDIT: What is PHP Nuke?
Ahh, that does make sense. However, I just use the table name for a field instead. IE, the "product" table has a "manufacturer" field in it. That and I never really use SQL statements for more than one table at a time. Like I said, hobby. //content.invisioncic.com/y282845/emoticons/wink.gif.608e3ea05f1a9f98611af0861652f8fb.gifIt helps when linking, tahts all.
If you have Prod.ID, and Manf.ID, when u try to use Manf.ID in the Prod table, you can't use the same Manuf.ID, because you already have a ID in PRod, so u'd have to change that foreign key to say Prod.ManufID.
So in Prod it's ManufID, but in Manuf its ID. Get what i'm saying? It's just good practice to distinguish IDs, since it's usually a Primary key, and Primary keys are mostly used for foreign keys.
I would have personally done it as so Prod.ProdID, Manuf.ManufID, so when i tie the Manuf to a Prod, it's Prod.ManufID same as Manuf.ManufID. MAkes life easier when coding, since they are equal in all tables. Get it? //content.invisioncic.com/y282845/emoticons/wink.gif.608e3ea05f1a9f98611af0861652f8fb.gif
Ahh! I see. SIN uses it, yes?it's a CMS - content management system.
here's a stock install on my httplayground;
http://www.kayrad.com/nuke