The "related article" results are the more relevant to the previous case, to find an efficient wording

My article system, want to follow multiple pieces under the strip
To see what the odds are.

Introduction to 4 -sheet Basics
Content Article Main Table
Id
Lid = related Collection ID, save format (+/-)
tags = id of the relevant tag, save format (+/-)
typeID = Category ID is only 1 digits
Anthology
Lid
Name

Tags
Id
Name
Classification
typeID
Name

typeID = Category ID, no, don't say more.
Tag = tag it doesn't have to be said,
Lid = A corpus, but an article can be put in a number of essays, such as: Php+mysql+ajax No refresh comments
User may put in PHP anthology, MySQL article, Ajax anthology

TAG is shared with all stations, repeat is not added, will only choose
So you can't make a classified list of your own articles, so there will be a corpus function

Because a section of the article already shows other articles of the current anthology

So in the section of the article, the text set in the document is no more than the tag article should be ranked in front

So the readiness of the relationship ranking is
1. Tag-related
2. Anthology
3. Latest Current classification articles

why divide 3 times???

Because I am afraid too tag, but also do not use the Corpus function ....
So the last step is the current category article


of the current article
TAG is 3,14
Lid = 7,12
typeID = 2

SELECT * from ' content ' WHERE ' tags ' in (3,14) ORDER by ' time ' DESC LIMIT 10
SELECT * from ' content ' WHERE ' lid ' in (7,12) ORDER by ' time ' DESC LIMIT 10
SELECT * from ' content ' WHERE ' typeid ' = ' 2 ' ORDER by ' time ' DESC LIMIT 10


Front desk showing 10 related articles
Would have been prepared, divided 3 times, and then each time to take 10 is the safest

Then think about ... This also has the merger array what also troublesome, the focus is to take too much information, but the front desk only needs 10 article

So replace it with a sentence
SELECT * from ' video_content ' WHERE ' tags ' in (3,14) or ' lid ' in (3) or ' typeid ' = 2 LIMIT 10

But this seems to be able to tag> anthology > Classification ... To rank

What's the way to ask?

Requirements seem to be very troublesome, hehe, because the bottom half of the page has 50% of the section is to display related articles, so it is important to operate

Reply to discussion (solution)

It's a little silly to use this piece of code temporarily.

What better way to suggest it?

Related articles if (!empty ($data ["tags"]) | |!empty ($data ["lid"]) {$tags = $data ["tags"]; $lid = $data ["lid"]; $tag _sql = "SELECT * F" ROM ' content ' WHERE ' tags ' in ($tags) OR ' lid ' in ($lid) the ORDER by ' time ' DESC LIMIT 8 "; $stmt = $pdo->prepare ($tag _sql); $stmt->execute (), $tags _v = $stmt->fetchall (PDO::FETCH_ASSOC), $smarty-Assign ("R_v", $tags _v);} $tags _num = count ($tags _v), if ($tags _num < 8) {$now _v = ""; foreach ($tags _v as $key + = $value) {$now  _v. = $val ue[' vid ']. ",";} $now _v=substr ("$now _v", 0,-1); $need = 8-$tags _num; $typeid = $data ["typeID"]; $typeid _sql = "SELECT * from ' content ' WHERE ' typeID ' = ' $typeid ' and  ' vid ' not in ($now _v) The ORDER by ' time ' DESC LIMIT $need "; $stmt = $pdo->prepare ($typeid _sql); $stmt->execute (), $typeid _v = $stmt->fetchall (PDO::FETCH_ASSOC), $smarty-Assign ("R_tv", $typeid _v);}

SQL is not good with or, not in;
If the data doesn't need to be too timely,
Put your 3 SQL statements together. Cache data for a period of time (half an hour, an hour, or even a little longer)
Because your data are dead data, no pageviews, no comments, etc.

SQL is not good with or, not in;
If the data doesn't need to be too timely,
Put your 3 SQL statements together. Cache data for a period of time (half an hour, an hour, or even a little longer)
Because your data are dead data, no pageviews, no comments, etc.

Thank you
I know that, too.

But the more you want to know is that if you follow the more relevant row more before

Is the first row tag and then platoon lid and then the same other articles

Can we only use the second floor method?

Do you mean if you want to 10 tag, first take 10 tags, not enough to take the LIB, then not enough to take the type?

If this is the case, your SQL is not a problem!

Do you mean if you want to 10 tag, first take 10 tags, not enough to take the LIB, then not enough to take the type?

If this is the case, your SQL is not a problem!

Yes

The 2 floor has temporarily made a simple
For the time being, tag and lid.

Not enough to take type again
and 2 floors with 8 tests.

Is there a better way to do it?

Use full-text search to do

