Jag vet att du redan har accepterat ett svar, men jag var halvvägs med att skriva detta så jag bestämde mig för att lägga upp det ändå.
Jag ska gå tillbaka lite innan jag förhoppningsvis svarar på din fråga. När du utvecklar applikationer och bygger databaser bör du ALLTID försök att strukturera saker så beskrivande och kompakt som möjligt. Det skulle vara riktigt besvärligt att ha en variabel/kolumn som heter color
och lagra krypterade användarlösenord där (konstigt, eller hur?). Det finns några standardiserade databasnamnkonventioner som, när de följs, gör livet mycket lättare, speciellt när man utvecklar komplicerade applikationer. Jag skulle råda dig att läsa några bloggar om namnkonventionerna. En bra utgångspunkt kan vara det här
en.
Jag inser fullt ut att med de föreslagna ändringarna nedan kan du behöva delvis/helt skriva om applikationskoden du har skrivit hittills, men det är upp till dig om du verkligen vill att saker ska fungera bättre.
Låt oss börja med att fixa databasstrukturen. Som det ser ut, gör du en applikation som liknar facebooks nyhetsflöde. I det här fallet använder du FOREIGN KEYS
är ganska obligatoriskt så att du kan garantera viss datakonsistens. Exempeldatabasschemat nedan visar hur du kan uppnå det.
-- Application users are stored here.
CREATE TABLE users (
user_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
first_name VARCHAR(255),
last_name VARCHAR(255),
profile_name VARCHAR(255)
) ENGINE=InnoDb;
-- User friendship relations go here
CREATE TABLE friends (
friend_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
profile_one INT NOT NULL,
profile_two INT NOT NULL,
FOREIGN KEY (profile_one) REFERENCES users (user_id),
FOREIGN KEY (profile_two) REFERENCES users (user_id)
) ENGINE=InnoDb;
-- User status updates go here
-- This is what will be displayed on the "newsfeed"
CREATE TABLE statuses (
status_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
author_id INT NOT NULL,
recipient_id INT NOT NULL,
message TEXT,
-- created date ?
-- last updated date ?
FOREIGN KEY (author_id) REFERENCES users (user_id),
FOREIGN KEY (recipient_id) REFERENCES users (user_id)
) ENGINE=InnoDb;
-- Replies to user statuses go here. (facebook style..)
-- This will be displayed as the response of a user to a certain status
-- regardless of the status's author.
CREATE TABLE replies (
reply_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
status_id INT NOT NULL,
author_id INT NOT NULL,
message TEXT,
FOREIGN KEY (status_id) REFERENCES statuses (status_id),
FOREIGN KEY (author_id) REFERENCES users (user_id)
) ENGINE=InnoDb;
Nu när detta är åtgärdat kan vi fortsätta med nästa steg - att välja nyhetsflödet för john123
(vem har user_id=1
). Detta kan uppnås med frågan nedan:
SET @search_id:=1; -- this variable contains the currently logged in user_id so that we don't need to replace the value more than once in the whole query.
SELECT
statuses.*,
author.first_name AS author_first_name,
author.last_name AS author_last_name,
recipient.first_name AS recipient_first_name,
recipient.last_name AS recipient_last_name
FROM statuses
JOIN users AS author ON author.user_id = statuses.author_id
JOIN users AS recipient ON recipient.user_id = statuses.recipient_id
WHERE (statuses.author_id = @search_id OR statuses.recipient_id = @search_id)
ORDER BY status_id ASC
Och här
du kunde se det i aktion i en sqlfiddle. Som du kan se, bara genom att strukturera databasen bättre, har jag eliminerat behovet av en underfråga (vilket är vad EXISTS / NOT EXISTS
gör enligt dokumenten och EXPLAIN
). Dessutom skulle ovanstående SQL-kod vara mycket lättare att underhålla och utöka.
Hur som helst, jag hoppas att du har nytta av detta.