ORDER BY Timestamp tra 2 tabelle

[blackskyisback]

Salve a tutti,

ho 2 tabelle in cui sono presenti un timestamp

Tabella 1

actor.last_update TIMESTAMP

Tabella 2

ptgweb.`update` TIMESTAMP

quello che vorrei ottenere e' fare il confronto dei TIMESTAMP delle 2 tabelle e' ordinarli per ordine di ultimo aggiornamento

o questa query ma il risultato non e' come mi aspettavo

SELECT
    actor.actor_id,
    actor.last_update,
    ptgweb.actor_id,
    ptgweb.`update` 
FROM
    actor
    INNER JOIN ptgweb ON actor.actor_id = ptgweb.actor_id 
ORDER BY
    TIMESTAMP ( actor.last_update, ptgweb.`update` ) 
    LIMIT 10 

[mzanella]

ORDER BY CASE
  WHEN actor.last_update > ptgweb.update
  THEN actor.last_update
  ELSE ptgweb.update
END

[blackskyisback]

Ciao mzanella

errore nella query

> 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE actor.last_update > ptgweb.update
THEN actor.last_update
ELSE ptgweb.upd' at line 10

[mzanella]

Ho scritto WHERE al posto di WHEN, ho corretto il messaggio iniziale.
Ovviamente la parte mostrata è solo quella di ordinamento, selezione e join restano quelle che già hai.

[blackskyisback]

me ne sono accorto dopo

come inserisco il LIMIT 10 DESC?

ricevo errore

SELECT
    actor.actor_id,
    actor.last_update,
    ptgweb.actor_id,
    ptgweb.`update` 
FROM
    actor
    INNER JOIN ptgweb ON actor.actor_id = ptgweb.actor_id 
ORDER BY CASE
WHEN actor.last_update > ptgweb.`update`
THEN actor.last_update
ELSE ptgweb.`update`
END
LIMIT 10 DESC 

[blackskyisback]

aggiungo che il risultato deve essere solo uno, o actor.last_update oppure ptgweb.`update`
dipende dall'ultimo aggiornamento
quindi penso che nella query andrebbe inserito anche un AS

[blackskyisback]

per LIMIT 10 DESC o risolto

SELECT
    actor.actor_id,
        actor.nome,
    actor.last_update,
    ptgweb.actor_id,
    ptgweb.`update` 
FROM
    actor
    INNER JOIN ptgweb ON actor.actor_id = ptgweb.actor_id
    ORDER BY 
CASE
WHEN actor.last_update > ptgweb.`update`
THEN actor.last_update
ELSE ptgweb.`update`
END
DESC
LIMIT 10 

rimane il discorso del risultato unico abbinato con AS

[blackskyisback]

o controllato, sembra che non serve un risultato unico, actor.last_update o ptgweb.`update restituiscono gli stessi risultati,
confermi mzanella?

comunque Grazie per il tuo prezioso aiuto

[mzanella]

Replica il case nel SELECT:

SELECT
  actor.actor_id,
  actor.nome,
  ptgweb.actor_id,
  CASE
    WHEN actor.last_update > ptgweb.`update`
    THEN actor.last_update
    ELSE ptgweb.`update`
  END AS update

[blackskyisback]

Replica il case nel SELECT:

SELECT
  actor.actor_id,
  actor.nome,
  ptgweb.actor_id,
  CASE
    WHEN actor.last_update > ptgweb.`update`
    THEN actor.last_update
    ELSE ptgweb.`update`
  END AS update

sbaglio qualcosa?

SELECT
    actor.actor_id,
        actor.nome,
    actor.last_update,
    ptgweb.actor_id,
    ptgweb.`update`
CASE
    WHEN actor.last_update > ptgweb.`update`
    THEN actor.last_update
    ELSE ptgweb.`update`
  END AS update 
FROM
    actor
    INNER JOIN ptgweb ON actor.actor_id = ptgweb.actor_id
    ORDER BY 
CASE
WHEN actor.last_update > ptgweb.`update`
THEN actor.last_update
ELSE ptgweb.`update`
END
DESC
LIMIT 10 

[blackskyisback]

sto effettuando dei test senza AS

inserito un record e i risultati sono diversi

prima query, l'aggiornamento non viene visualizzato, nemmeno con LEFT JOIN

SELECT
    actor.actor_id,
        actor.nome,
    actor.last_update,
    ptgweb.actor_id,
    ptgweb.`update` 
FROM
    actor
    LEFT JOIN ptgweb ON actor.actor_id = ptgweb.actor_id
    ORDER BY 
(CASE
WHEN actor.last_update > ptgweb.`update`
THEN actor.last_update
ELSE ptgweb.`update`
END)
DESC
LIMIT 10 

seconda query, scambiato i valori in CASE e l'aggiornamento viene visualizzato

SELECT
    actor.actor_id,
        actor.nome,
    actor.last_update,
    ptgweb.actor_id,
    ptgweb.`update` 
FROM
    actor
    LEFT JOIN ptgweb ON actor.actor_id = ptgweb.actor_id
    ORDER BY 
(CASE
WHEN ptgweb.`update` > actor.last_update
THEN ptgweb.`update`
ELSE actor.last_update
END)
DESC
LIMIT 10 

la seconda query sembra che sia quella corretta, ora io vorrei inserire oltre al falemico alias (AS) anche una terza tabella chiamata ptgweb2
come fare dato che i valori da controllare sono tre

actor.last_update

ptgweb.`update`

ptgweb2.`update`

altra questione, che succede se viene aggiornato actor.last_update e gli altri TIMESTAMP sono vuoti?

[mzanella]

seconda query, scambiato i valori in CASE e l'aggiornamento viene visualizzato [...] la seconda query sembra che sia quella corretta

Questa non è una soluzione, è un sintomo di un problema più grosso alla base. Com'è possibile che un record non abbia un valore nel campo update? Il solo fatto che quel record esista significa che ha subito almeno una modifica, ovvero la propria creazione, quindi update deve essere almeno uguale o successivo alla data di inserimento, mai NULL.

ora io vorrei inserire oltre al falemico alias (AS) anche una terza tabella chiamata ptgweb2
come fare dato che i valori da controllare sono tre

Il fatto che stia per comparire una tabella che si chiama ptgweb2 è già di per se un campanello d'allarme. Cosa aggiunge rispetto alla ptgweb? Se è significativamente diversa perché si chiama allo stesso modo? E se non lo è perché diventa una tabella separata?
Controllare tre o più valori, comunque, è la stessa cosa che controllarne due, va usato sempre un CASE.

[blackskyisback]

ptgweb a questa schema (e anche ptgweb2)



actor_id

collegato con la tabella actor e actor_id

websites

e dove vengono inseriti i dati prelevati dallo scraping

url

e l'indirizzo che inserisco manualmente e serve allo script scraping per aggiornare websites

update (TIMESTAMP)

quando inserisco actor_id e url questo viene settato a 0000-00-00 00:00:00
dopo l'aggiornamento di websites viene restituita la data di TIMESTAMP
esempio
2021-03-16 10:51:58

Il fatto che stia per comparire una tabella che si chiama ptgweb2 è già di per se un campanello d'allarme. Cosa aggiunge rispetto alla ptgweb? Se è significativamente diversa perché si chiama allo stesso modo? E se non lo è perché diventa una tabella separata?

perche' deve contenere i dati di un altro sito e l'update deve essere diverso

Controllare tre o più valori, comunque, è la stessa cosa che controllarne due, va usato sempre un CASE.

a farlo, gia' con AS ho errore, figuriamoci inserire 2 case

[mzanella]

perche' deve contenere i dati di un altro sito e l'update deve essere diverso

Allora è chiaro che la struttura dell'informazione sia la stessa, devi usare un'unica tabella. La colonna url sembra già una buona candidata per far pare di una chiave primaria composta (actor_id, url), per migliorare le prestazioni puoi anche definire un indice su actor_id.

a farlo, gia' con AS ho errore, figuriamoci inserire 2 case

...a maggior ragione conviene un'unica tabella.

quando inserisco actor_id e url questo viene settato a 0000-00-00 00:00:00

Quindi, guardando la tua tabella e immaginando un dialogo, verrebbe una scena simile:
- Quando hai inserito l'actor?
- il 16 marzo 2021
- E quando lo hai aggiornato l'ultima volta?
- a mezzanotte dell'anno 0, quando è nato Gesù
Forse c'è qualcosa che non va... no?
Hai un problema di integrità. Modifica lo schema della tabella in modo che update si aggiorni automaticamente ad ogni modifica, per esempio ricreando la tabella come

CREATE TABLE ...
  update TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
...

Già che ci siamo, prova ad assegnare un nome significativo alla colonna websites. Vista così sembra che contenga una lista di siti web che parlano dell'attore, mentre contengono invece i dati ottenuti tramite scraping. Un nome più significativo sarebbe quindi scraped_data.

[blackskyisback]

quando inserisco actor_id e url questo viene settato a 0000-00-00 00:00:00
Quindi, guardando la tua tabella e immaginando un dialogo, verrebbe una scena simile:
- Quando hai inserito l'actor?
- il 16 marzo 2021
- E quando lo hai aggiornato l'ultima volta?
- a mezzanotte dell'anno 0, quando è nato Gesù
Forse c'è qualcosa che non va... no?
Hai un problema di integrità. Modifica lo schema della tabella in modo che update si aggiorni automaticamente ad ogni modifica, per esempio ricreando la tabella come

e invece secondo me la logica e' corretta
quando inserisco l'attore nella tabella actor viene aggiornato il campo

actor.last_update

nella tabella ptgweb quando inserisco url e actor_id viene settato a 0 ptgweb.`update

perche' e corretto?
perche' ancora non e' stato inserito nessun dato in websites e forse mai verra' inserito

il valore di riferimento e' adesso actor.last_update

solamente quando aggiorno websites allora ptgweb.`update puo' restituirmi il Timestamp

se effettuo la modifica come dici tu mi ritrovo con un ptgweb.`update aggiornato

ma websites risulta vuoto

non so' se mi sono sspiegato, magari il ragionamento e' un po' contorto

[blackskyisback]

dimenticavo,
perche' 2 tabelle diverse? ptgweb e ptgweb2

il motivo e' che hanno dati diversi e un update diverso

se integro i dati in una tabella unica con un solo update non si riesce a capire quando e' stato effettuato l'aggiornamento di dei 2 websites

[mzanella]

perche' e corretto?
perche' ancora non e' stato inserito nessun dato in websites e forse mai verra' inserito

Questo è un altro problema ancora, anzi due: da un lato hai inconsistenza, ovvero hai una riga in una tabella che non contiene tutti i dati, dall'altro è una situazione che dovresti gestire guardando se il contenuto di websites è NULL, non il campo update.

Più nel dettaglio, il primo problema indica che stai scrivendo una riga in un database (momentaneamente) inutile: è lì, ma non serve a niente, perché non ha dati da leggere. Servirà quando uno scraper userà il contenuto di url per fare delle cose il cui risultato andrà ri-salvato in websites (scraped_data). Ma allora conviene posticipare l'inserimento nella tabella a quando i dati saranno effettivamente disponibili. Questo può richiedere, eventualmente lo spostamento dell'informazione "parziale" di actor_id, url in una tabella differente che rappresenta una coda di operazioni da svolgere (o qualcosa di simile). Un altro effetto negativo dell'approccio che stai seguendo attualmente è quello che tu stesso hai indicato: "forse [nessun dato] verrà mai inserito", quindi oltre ad avere informazione incompleta stai anche occupando risorse (benché poche) inutilmente.

Il secondo problema è ortogonale. Stai dando per scontato che, se "update" (che non rappresenta un update) è maggiore di 0, allora websites (che non rappresenta dei websites) allora è certamente diverso da NULL. Quest'assunzione non è dimostrabile basandosi sullo schema del database, stai quindi delegando la correttezza del sistema a quella del codice PHP, il che è un campanello d'allarme. La soluzione in realtà è semplicissima: se vuoi recuperare solo dati aggiornati e non nulli... usa una query che recuperi solo dati aggiornati e non nulli!

SELECT ... WHERE update > ... AND websites IS NOT NULL

e invece secondo me la logica e' corretta

Temo non ci siano argomentazioni ragionevoli per avere riga risulti aggiornata 2021 anni prima di essere stata creata.
La logica non è corretta, è piuttosto una pezza che sei riuscito a mettere sul codice per farlo funzionare. Adesso bisogna passare da "funziona" a "a prova di bomba".

il motivo e' che hanno dati diversi e un update diverso

se integro i dati in una tabella unica con un solo update non si riesce a capire quando e' stato effettuato l'aggiornamento di dei 2 websites

Sbagliato, almeno rispetto a quanto dicevi prima. La struttura dell'informazione è la stessa: id attore, fonte (url), dati letti e momento dell'ultima lettura. La fonte sarà diversa (o avrà un prefisso diverso) tra siti diversi che parlano dello stesso attore, hai quindi tutte le informazioni necessarie. Potresti avere, per esempio, i dati di uno stesso attore provenienti da un sito aggiornati il 16 marzo, e quelli provenienti da un altro sito aggiornati il 5 marzo, questo può stare benissimo in due righe distinte. L'aggiornamento più recente per l'attore risulterà il massimo dei timestamp che appartengono a righe associate a quell'attore e hanno scraped_data NOT NULL. Le query diventeranno un po' più complesse, ma comunque meno rispetto all'approccio che useresti con più tabelle.

[blackskyisback]

l motivo e' che hanno dati diversi e un update diverso

se integro i dati in una tabella unica con un solo update non si riesce a capire quando e' stato effettuato l'aggiornamento di dei 2 websites
Sbagliato, almeno rispetto a quanto dicevi prima. La struttura dell'informazione è la stessa: id attore, fonte (url), dati letti e momento dell'ultima lettura. La fonte sarà diversa (o avrà un prefisso diverso) tra siti diversi che parlano dello stesso attore, hai quindi tutte le informazioni necessarie. Potresti avere, per esempio, i dati di uno stesso attore provenienti da un sito aggiornati il 16 marzo, e quelli provenienti da un altro sito aggiornati il 5 marzo, questo può stare benissimo in due righe distinte. L'aggiornamento più recente per l'attore risulterà il massimo dei timestamp che appartengono a righe associate a quell'attore e hanno scraped_data NOT NULL. Le query diventeranno un po' più complesse, ma comunque meno rispetto all'approccio che useresti con più tabelle.

stessa tabella con tutti i dati e update diversi? come e' possibile?
o metto 2 timestamp e anche qui c'e' il problema ad associare quello giusto a websites

boh

d'altronde mi hai suggerito tu che i dati devono stare in piu' tabelle diverse e poi ricuperarli tramite query, o mi perdo qualcosa oppure...

comunque la query attualmente sembra funzionare, non sono sicuro al 100%, lo vedro' nei prossimi giorni quando inserisco nuovi dati nelle 2 tabelle

resta il problema del CASE con 3 tabelle, cosa che ho provato a fare ma o fallito

actor.last_update
ptgweb_update
ptgweb2_update

[mzanella]

stessa tabella con tutti i dati e update diversi? come e' possibile?

Una tabella non rappresenta un dato, rappresenta una struttura.
Se immagini una tabella che rappresenta la cronologia delle chiamate telefoniche, hai numero del mittente, operatore, numero del destinatario e durata della telefonata. Non è rilevante se due numeri appartengano a una singola persona, se hanno operatori diversi, eccetera, la tabella rappresenta la struttura di ogni chiamata telefonica.

Nel caso dello scraping, la tabella tiene traccia dell'attore (id), della fonte (url), del contenuto e della data di aggiornamento per ogni pagina di cui è stato fatto lo scraping. Se per uno stesso attore è stato fatto scraping da due fonti diverse, ci saranno due righe nella tabella:

actor_id |              url | scraped_data |              update
      42 | http://site1.com | <html>...    | 2021-03-16 10:03:15
      42 | http://site2.com | <html>...    | 2021-03-10 16:49:25

Se vuoi conoscere la data di aggiornamento più recente per un attore (e hai seguito l'indicazione di non avere dati parziali nella tabella) hai a disposizione:

SELECT MAX(update) FROM pgtweb WHERE actor_id = 42

semplice e pulito

Se non hai seguito l'indicazione di non avere dati parziali, dovrai aggiungere un'ulteriore condizione:

SELECT MAX(update) FROM pgtweb WHERE actor_id = 42 AND scraped_data IS NOT NULL

Questo codice funziona a prescindere dal numero di siti diversi da cui fai scraping.

Per contro, supponiamo che il tuo sistema si sviluppi fino ad avere 10 siti da cui fare scraping. Con l'approccio che stai seguendo, questo vuol dire 10 tabelle. La stessa query vista una paio di righe sopra diventerebbe:

SELECT
  CASE pgtweb.update > pgtweb2.update AND pgtweb.update > pgtweb3.update AND pgtweb.update > pgtweb4.update AND pgtweb.update > pgtweb5.update AND pgtweb.update > pgtweb6.update AND pgtweb.update > pgtweb7.update AND pgtweb.update > pgtweb8.update AND pgtweb.update > pgtweb9.update AND pgtweb.update > pgtweb10.update
  THEN pgtweb.update
  CASE pgtweb2.update > pgtweb.update AND pgtweb2.update > pgtweb3.update AND pgtweb2.update > pgtweb4.update AND pgtweb2.update > pgtweb5.update AND pgtweb2.update > pgtweb6.update AND pgtweb2.update > pgtweb7.update AND pgtweb2.update > pgtweb8.update AND pgtweb2.update > pgtweb9.update AND pgtweb2.update > pgtweb10.update
  THEN pgtweb2.update
  CASE pgtweb3.update > ...
  THEN pgtweb3.update
  CASE pgtweb4.update > ...
  THEN pgtweb4.update
  CASE pgtweb5.update > ...
  THEN pgtweb5.update
  CASE pgtweb6.update > ...
  THEN pgtweb6.update
  CASE pgtweb7.update > ...
  THEN pgtweb7.update
  CASE pgtweb8.update > ...
  THEN pgtweb8.update
  CASE pgtweb9.update > ...
  THEN pgtweb9.update
  ELSE pgtweb10.update
  AS update
  FROM pgtweb NATURAL JOIN pgtweb2 NATURAL JOIN pgtweb3 NATURAL JOIN pgtweb4 NATURAL JOIN pgtweb5 NATURAL JOIN pgtweb6 NATURAL JOIN pgtweb7 NATURAL JOIN pgtweb8 NATURAL JOIN pgtweb9 NATURAL JOIN pgtweb10

... quale preferisci?

[blackskyisback]

Nel caso dello scraping, la tabella tiene traccia dell'attore (id), della fonte (url), del contenuto e della data di aggiornamento per ogni pagina di cui è stato fatto lo scraping. Se per uno stesso attore è stato fatto scraping da due fonti diverse, ci saranno due righe nella tabella:
Codice:

actor_id | url | scraped_data | update
42 | http://site1.com | <html>... | 2021-03-16 10:03:15
42 | http://site2.com | <html>... | 2021-03-10 16:49:25

hai dimenticato questo

tabella ptgweb collegata con actor tramite actor_id

Se vuoi conoscere la data di aggiornamento più recente per un attore (e hai seguito l'indicazione di non avere dati parziali nella tabella) hai a disposizione:
Codice:

SELECT MAX(update) FROM pgtweb WHERE actor_id = 42

semplice e pulito

Se non hai seguito l'indicazione di non avere dati parziali, dovrai aggiungere un'ulteriore condizione:
Codice:

SELECT MAX(update) FROM pgtweb WHERE actor_id = 42 AND scraped_data IS NOT NULL

questa magari potrebbe andare ma dovrebbe scansionare le 3 tabelle che ricordo hanno il TIMESTAMP con nomi differenti tra actor

actor.last_update

ptgweb.update

ptgweb2.update

[mzanella]

hai dimenticato questo

tabella ptgweb collegata con actor tramite actor_id

No che non l'ho dimenticato, l'avevo indicato chiaramente nel messaggio 14:

La colonna url sembra già una buona candidata per far pare di una chiave primaria composta (actor_id, url) [...]

[blackskyisback]

ok, avevo capito male
in effetti utilizzare url come chiave primaria non e' una cattiva idea ma....

ma la chiave primaria non e' INT? li invece il campo e' varchar

quindi come inserisco i dati testuali li?

preciso che quello che voglio ottenere non e' l'ultimo aggiornamento per attore singolo ma una lista che mi visualizza gli ultimi 10 aggiornati tra le 3 tabelle

[mzanella]

Una chiave primaria può essere di (quasi) qualsiasi tipo, incluso un tipo composto

[blackskyisback]

Una chiave primaria può essere di (quasi) qualsiasi tipo, incluso un tipo composto

interessante questo non lo sapevo, pensavo che la chiave primaria si poteva associare solo a un intero

quindi la procedura da eseguire sarebbe questa

tabella ptgweb



actor_id
togliere la chiave primaria presente, la relazione penso che venga sempre mantenuta

url
inserire la chiave primaria, senza autoincrement

websites
rinominare websites in scraped_data1 ed inserire un altro scraped_data2

update
rimane questo senza ulteriori modifiche

esatto?

[mzanella]

Non hai bisogno di scraped_data1 e scraped_data2, altrimenti c'è lo stesso problema dell'avere due tabelle (i.e. 10 siti = 10 colonne, per ogni nuovo sito devi andare a modificare la struttura del database e tutte le query). Basta un'unica colonna scraped_data, dati letti da siti diversi verranno inserite in righe diverse, per questo l'url concorre alla chiave primaria:

actor_id |              url | scraped_data |              update
      42 | http://site1.com |    <html>... | 2021-03-16 10:03:15
      42 | http://site2.com |    <html>... | 2021-03-10 16:49:25

[blackskyisback]

Non hai bisogno di scraped_data1 e scraped_data2, altrimenti c'è lo stesso problema dell'avere due tabelle (i.e. 10 siti = 10 colonne, per ogni nuovo sito devi andare a modificare la struttura del database e tutte le query). Basta un'unica colonna scraped_data, dati letti da siti diversi verranno inserite in righe diverse, per questo l'url concorre alla chiave primaria:

actor_id |              url | scraped_data |              update
      42 | http://site1.com |    <html>... | 2021-03-16 10:03:15
      42 | http://site2.com |    <html>... | 2021-03-10 16:49:25

e invece temo che sia necessario, e ti spiego perche'

caso 1 = visualizzare la lista attori utilizzando il CASE

Select nome, update from ... DESC LIMIT 10;

qui il sistema sopra e' ottimo

caso 2: scheda attore e tab website (sono 2)

Select url, update from ... WHERE film_actor.actor_id = " . $actor_id;

e qui incominciano i guai

siccome la query e per per actor_id in questo caso nella tab del sito 1 vengono visualizzati 2 Timestamp con url
e nel tab del sito 2 uguale

esempio:

Tab Website 1
actor_id | url | scraped_data | update
42 | http://site1.com | <html>... | 2021-03-16 10:03:15
42 | http://site2.com | <html>... | 2021-03-10 16:49:25

Tab Weebsite 2
actor_id | url | scraped_data | update
42 | http://site1.com | <html>... | 2021-03-16 10:03:15
42 | http://site2.com | <html>... | 2021-03-10 16:49:25

e non va bene

[blackskyisback]

per Tab intendo questo

[mzanella]

caso 2: scheda attore e tab website (sono 2)

Select url, update from ... WHERE film_actor.actor_id = " . $actor_id;

e qui incominciano i guai

Bisogna scrivere la query corretta. Se lo scopo è mostrare i dati di un attore ottenuti da un determinato sito web, la query deve ovviamente contenere una clausola sia per l'attore e che per il sito web:

SELECT url, update FROM ... WHERE actord_id = 42 AND url LIKE "%sito1.com%";

Quello che stai cercando di fare tu era rimuovere l'informazione relativa al sito web dal posto in cui dovrebbe stare (i.e. il concetto di WHERE) verso una colonna artificiale. Così facendo renderesti il sistema instabile e inutilmente più complesso, perderesti inoltre la possibilità di eseguire alcune operazioni che potrebbero essere interessanti, oltre a introdurre il problema del singolo update associato a una quantità finita ma illimitati di fonti di scraping.

[blackskyisback]

SELECT url, update FROM ... WHERE actord_id = 42 AND url LIKE "%sito1.com%"; 

url LIKE "%sito1.com%";

devo ogni volta scrivere l'indirizzo?

non mi sembra una soluzione comoda

si potrebbe identificare il website1 o 2 cosi

url
numero



e la query diventa

SELECT url, update FROM ... WHERE actord_id = 42 AND numero LIKE "sito1"; 

o

SELECT url, update FROM ... WHERE actord_id = 42 AND numero LIKE "sito2"; 

[mzanella]

Questo dipende da quanta e quale informazione vuoi associare all'entità sito.
Se confronti la query che ti ho proposto con quella scritta da te:

SELECT url, update FROM ... WHERE actord_id = 42 AND url LIKE "%sito1.com%";

SELECT url, update FROM ... WHERE actord_id = 42 AND numero LIKE "sito1";

puoi vedere che sono praticamente identiche, a parte i '%'. Non è necessario scrivere l'intero url nel primo caso, basta il nome del sito, lasciando che LIKE e % facciano il resto.

Se hai informazioni semantiche da aggiungere ai siti si può comunque fare di meglio: l'uso di enum in questo caso è un'ulteriore pezza messa sul codice, puoi invece separare il concetto di fonte (source) per lo scraping in una tabella dedicata:

CREATE TABLE source (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  url VARCHAR(255) NOT NULL
);

e aggiungere, nella tabella pgtweb la colonna source_id. Così facendo la chiave primaria diventa (actor_id, source_id), e le query:

SELECT url, update FROM ... WHERE actor_id = 42 AND source_id = 84