Hvordan vælger man indlæg, der er oprettet af mig eller mine venner i et nyhedsfeed?

Jeg ved, at du allerede har accepteret et svar, men jeg var halvvejs ved at skrive dette, så jeg besluttede at sende det alligevel.

Jeg vil gå lidt tilbage, før jeg forhåbentlig svarer på dit spørgsmål. Når du udvikler applikationer og opbygger databaser, bør du ALTID prøv at strukturere tingene så beskrivende og kompakt som muligt. Det ville være virkelig akavet at have en variabel/kolonne ved navn color og gem krypterede brugeradgangskoder der (underligt, ikke?). Der er nogle standard databasenavnekonventioner, som, når de følges, gør livet meget lettere, især når man udvikler komplicerede applikationer. Jeg vil råde dig til at læse nogle blogs om navnekonventionerne. Et godt udgangspunkt kan være dette en.

Jeg er fuldt ud klar over, at med de foreslåede ændringer nedenfor kan det være nødvendigt delvist/fuldstændigt at omskrive den ansøgningskode, du har skrevet indtil nu, men det er op til dig, om du virkelig ønsker, at tingene fungerer bedre.

Lad os starte med at rette databasestrukturen. Som det ser ud, laver du en applikation, der ligner facebooks nyhedsfeed. I dette tilfælde skal du bruge FOREIGN KEYS er stort set obligatorisk, så du kan garantere en vis datakonsistens. Eksemplet på databaseskemaet nedenfor viser, hvordan du kan opnå 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 hvor dette er rettet, kunne vi fortsætte med næste trin - valg af nyhedsfeed for john123 (hvem har user_id=1 ). Dette kan opnås med forespørgslen nedenfor:

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

Og her du kunne se det i aktion i en sqlfiddle. Som du kan se, blot ved at strukturere databasen bedre, har jeg elimineret behovet for en underforespørgsel (som er hvad EXISTS / NOT EXISTS gør i henhold til dokumenterne og EXPLAIN ). Desuden ville ovenstående SQL-kode være meget nemmere at vedligeholde og udvide.

Jeg håber i hvert fald, at du finder dette nyttigt.