Apr 8, 2004, 8:10 PM
Veteran / Moderator (6956 posts)
Apr 8, 2004, 8:10 PM
Post #29 of 33
Views: 2611
Hi,
Maybe I got something wrong when I read the message. I ended up with a headache+migraine that knocked me out for about 6 hours. Worst one I've had in a long, long time.
But, the concept here is still a "quick fix" vs the more useful/elegant/proper/? solution.
If a link/node/leaf, in this case a Link record, needs some sort of other data to qualify it, eg: Location, color, size, manufacturer, etc it should be included as a field in the Link record. If there is a business classification system, then the category of the business should also be included, such as the category in a yellow pages. Don't rely on the category hierarchy -- a convenience thing -- to determine the characteristics of the node data.
Part of data normalization is recoverability, data integrity, etc. which is why no database is ever perfectly normalized, but usuallybrought to a 3rd normal (more or less) level.
In the case of this link, a category/categorization field eg "Hairdresser" should be included in the link. Also the location of the link. City, State, Zip, or whatever unique localization information would give the user the data/information they need.
In the case of the link being orphaned from the category hierarchy, there is enough information to know that this link is a business class "Hairdresser" and in the region/location of "city, state, zip".
That link could be "automatically" recategorized, even if the actual category layout changed.
On top of that, in a search, the node/leaf contains enough information to uniquely identify it, as well as categorize it for the users search.
Links SQl got rid of the concept of primary categories, and even category ownership of a link to allow related, multiple and other category features. While in general,that is a good thing, sometimes building in some of the data contained in a "primary category" system is also a good thing -- especially for a true directory were there are several attributes of the link that are important -- eg type of business & location in this case.
So, the true solution here, as evidenced by the last few messages even, is a change to the Links table to reflect the data people are trying to use, rather than relying on keywords being present in the title, description or even category placement of the link.
Adding in a "Category" and "Location" or "City" field (depending on the scope of the directory) would solve the problem better. In that case, someone could do a search on "Essex" to find any businesses that were in any category and perhaps be surprised at what they found (ie: a bead shop popping up out of the list <G>) The link could be classified under "Hairdressers", "Personal Grooming", "Beauty & health", "Spas" or "Essex" and still be found on a search or perusal of the category system (if the link.html showed that data).
So, the fix is to change the link record, and the type of data collected and associated with the link.
A quick fix, as outlined here, is to give a potential keyword assist.
But, as the directory grows and changes, the long-term fix is a better solution, and can be started now, and worked backwards as links are updated, but going forward, new links will have the proper classification (search) data associated with them.
Not trying to be a pain, really. While andy is running around having fun with coding, I've been stuck with a few situations of redesiging somewhat complex databases. It's like those logic problems where you get a story and a bunch of clues like who is sleeping with whom, and what color car they drive, and you need to figure out if they smoke or like roast beef sandwiches :)
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Hi,