简单的搜索功能，带有用于MySQL数据库的php中的固定标签

Question

I'm about to build a simple search function in php. Most important is speed, I want it to be as light weight as possible.

User is going to search for articles with already defined tags. There's going to be between 1k - 5k articles and just a few keywords. The user frequency of the search function will be quite high.

For example if user selects "color:blue" and "size:large" only articles with these tags should return.

Since there is just a few tags and many more articles i guess it's faster to have a table with the tags and article-id´s.

So my first thought was to store a data string of article-id´s with every term. But what I know and heard this is not good practice. Still it feels like it should be lighter and faster?

Article -id -name -etc

Tags -id -name -all related art-ids

I also seen examples of using an third table like this:

Article -id -name -etc

ArticleTagRelation -FKey art-id -FKey tag-id

Tags -id -name -etc

The third alternative I can think of is storing a data string of terms with every article (just one table).

Article -id -name -tags -etc

In my case, what would be the fastest in performance way to go?

Answer 1

You should use the three-table-solution in every circumstance! Storing multiple Tags in one column will make it impossible to ever get a fast lookup.

To understand this behaviour, it's important to know Databases internally organize data. They create sorted indizes, which make it possible to do lookups in very short time. However, this is only possible if the data is split into the correct columns.

If you use either of the other solutions, the database system has to inspect one of the columns, split the value up, and do a search for every substring. As this can't be done with sql (at least without dirty hacks), you'll have to programm these in PHP, which will lead to incredible bad performance, as your code will query the RDBMS for every row.

To give a few measurements: I just setup the following three tables:

CREATE TABLE tags (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `name` varchar(20) NOT NULL,
    PRIMARY KEY (`id`)
) ENGINE=`InnoDB`;

CREATE TABLE articles_tags (
    `article` int(11) NOT NULL,
    `tag` int(11) NOT NULL,
    PRIMARY KEY (`tag`,`article`)
) ENGINE=`InnoDB`;

CREATE TABLE articles (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `name` varchar(32) NOT NULL,
    `content` text NOT NULL,
    PRIMARY KEY (`id`)
) ENGINE=`InnoDB`;

• tags: I inserted 15 Tags consisting of 1-2 words
• articles: I inserted 2000 Articles with large random texts
• articles_tags: I inserted ~19k entries merging random articles with random tags

Then I executed the following queries, in a standard MySQL-Configuration (128MB innodb_buffer_pool_size) on a Desktop-Class 2.2GHz CPU

SELECT articles.name FROM articles 
INNER JOIN articles_tags ON articles.ID=article
INNER JOIN tags ON tags.id=tag
WHERE tags.name = '/*one of the tags, random*/'

This took 19.308 seconds for 10000 queries, which menas an average of 0.0019s/query, so i think a it should be no problem to have higher loads with a properly tuned server Also note that these measurements are without any query caching. They are completely random, it's not the same query over and over. In a good Server environment, you should have no problems serving a few 100k searches per seconds.

An important note to the primary key: The order of the columns in a primary key / additional index matters! If you often need to look up the reverse order (find tags belonging to a given article name), you should add an additional index for the other direction!