It sounds like what I suggested would work, but it's not a Normalized way of doing business in a relational database, is that right?
I'm interested in this because at some point I need to do pretty much the same thing for Photographers. They will need to be classified by Location and Type as well, since both ways of looking for them are necessary.
The only downside I can see is that by running an abnormal database I could run into problems down the road should I decide to port the data to another program besides Links.
Since LinksSQL allows for multiple entries in a single field, is there a problem if I always use Links for my database?
I'm very reluctant to modify the .cgi scripts because of the problems upgrading to newer versions once there are too many alterations to the code. So, adding more tables also presents it's own set of problems when dealing with Links, and it's really a question of which solution has fewer potential problems from the administrators point of view.
So, I guess my question is, what's the worst that can happen by violating the Normal Form Rules?
Bryan
I'm interested in this because at some point I need to do pretty much the same thing for Photographers. They will need to be classified by Location and Type as well, since both ways of looking for them are necessary.
The only downside I can see is that by running an abnormal database I could run into problems down the road should I decide to port the data to another program besides Links.
Since LinksSQL allows for multiple entries in a single field, is there a problem if I always use Links for my database?
I'm very reluctant to modify the .cgi scripts because of the problems upgrading to newer versions once there are too many alterations to the code. So, adding more tables also presents it's own set of problems when dealing with Links, and it's really a question of which solution has fewer potential problems from the administrators point of view.
So, I guess my question is, what's the worst that can happen by violating the Normal Form Rules?
Bryan