Despite what the title of this month's article implies, this installment of Tales From the List is not about a CFDJ-List thread regarding the meaning of life. It's about something much more important: metadata.

Metadata, in a nutshell, is information about information. It's how data is described, categorized, and conceptualized, and is also commonly used to show a relationship between different pieces of information. Some sort of metadata implementation is often required to meet Web application business requirements, and this month's featured CFDJ-List thread is all about a post inquiring about how best to meet such a business requirement.

The thread we will examine began when Tammy Hong, a CFDJ-List regular, wrote to the List saying that she had been asked to build an application that allows end users to search for images based on keywords, and she had two dilemmas. One dilemma was whether to use Access or SQL Server for the database.

Knowing that SQL Server is more robust, she's looking for more detailed reasoning to use that is specific to the application business requirements. The second dilemma was how to best structure the database so that when an end user submits a search, only images with matching keywords are returned. She was already aware of the best practice of storing the location of the image as a string in the database (rather than the image itself), but was unaware of any other "best practices" that apply to the design of an application with her requirements.

I-Lin Kuo, a long-time CFDJ-List regular well-known for his database expertise, suggested that this type of search functionality is best implemented using text indexing and that, because Access does not support text indexing, SQL Server would be a much better RDBMS platform.

He added that text indexing is much faster and allows for stemming and ranked matches, although it does have a steeper learning curve because RDBMS proprietary SQL extensions are used to leverage it. He then noted that he advises never performing a LIKE "%word%" SQL search because of the performance impact.

Kola Oyedeji responded, stating that he assumed I-Lin was referring to SQL Server Full Text Indexing, and wanted to know whether I-Lin knew of similar implementations on other RDBMS platforms? I-Lin responded, stating that Oracle has "Text Indexing," which in his experience is better than SQL Server's "Full Text Indexing," though he certainly does think the SQL Server implementation is pretty good.

He went on to further clarify his statement about LIKE searches, pointing out that in a LIKE search every row of data has to be looped over, whereas in text indexing, the database creates a "dictionary" of words that is optimized to be read very quickly to look up matching rows by applying a "matching algorithm" to the index. He pointed out that the downside is that newly inserted data may not be immediately available in the index and that there's a lot of overhead in the routine that runs to build an index - especially in large tables and columns.

While I also advocate the use of text indexing, I responded to I-Lin's post to point out that case insensitivity may be achieved with LIKE searches, which he hadn't mentioned.

Tammy thanked everyone for their input and rephrased and reposted her original question regarding the recommended table structure to use. I suggested creating one table that contained a unique ID as well as the path of an image, another table containing only a unique ID column and a column containing a single (unique) keyword, and a third (join) table with a unique ID and a unique ID from each of the other two tables (foreign keys).

The majority of experienced developers would most likely immediately approach the database structure this way, as it's a textbook example of a normalized structure. I-Lin Kuo offered an alternative that most developers would not usually consider, but he had a very interesting explanation.

I-Lin suggested that my solution was good when not using text indexing, but suggests that one table with the image location and a column with all of that image's metadata (keywords) in it would actually suit Tammy's needs quite nicely. He explained that this is because the text index would essentially be doing the same thing for you (building the table of keyword lookups for the images) under the hood - without the developer having to do the work. What's more, no table joins would be required to access that data, and keyword redundancy techniques could be implemented.

This is a very interesting point. While one of the benefits and goals of the normalized structure is to have as little data as possible ever be replicated (for example, the text for each actual keyword occurs only once - in the unique keyword table), one of the features of text indexing is that it "ranks" or "scores" your results. A developer can use the same word twice (or more) to describe an image in order to give it more "weight." Imagine that - sometimes redundancy is a good thing!!

I responded to I-Lin's post, noting that there is a serious advantage to the normalized approach in that the keywords themselves are reusable (for cross-referencing and the like) across all of the tables in a database when extrapolated into their own table - something his approach does not allow. I also pointed out that in the normalized design, tables could still be text indexed to speed up lookups. His response was that until Tammy had a reason to normalize the data, why not subscribe to the Extreme Programming maxim of "Do the simplest thing that works" and normalize the data later if the need ever arises? Ultimately, this is where I-Lin and I could not see eye-to-eye.

A posting by Devandra Shrikhande followed I-Lin's and my back-and-forth discussion, pointing out that another obvious benefit of normalizing the data is the ability to easily present the user with a list of available keywords to choose from. The thread also prompted a follow-up response by Amit Talwar, who brought up yet another very interesting point.

Amit reminded us that his preference is to use a database view whenever he needs data in a nonnormalized format. He also mentioned that SQL Server does not let you Full Text Index a view, but that of all the features he'd like to see added to SQL Server, the ability to do so is on the top of his list. If anyone from the SQL Server development team is reading this article - I have to agree with Amit - this would be a killer feature. Amit also reminded us that data inserted into a database via the Web often has to be made available immediately, and that in these situations, text indexing is not a good strategy - which is extremely important to keep in mind and was a very good point to have ended the thread on.

There never was a conclusive decision as to whether it's better to Full Text Index a nonnormalized table or to normalize your tables. However, as a result of I-Lin's thinking "outside the box," a very interesting and educational discussion was born. It taught us all a little bit about the pros and cons of text indexing versus normalizing your tables. Most important of all, it showed the benefit of challenging and rethinking even the most widely accepted techniques and common-sense solutions. That, after all, is what development is all about.

• Tales Keep Prospects Talking