[MySql] Sito avente campo di ricerca

[ANTAGONIA]

Buon pomeriggio a tutti.
E' la prima volta che mi capita di dover fare un sito, dove c'è la classica casella di ricerca, dove l'utente inserisce una parola e poi visualizza il o i risultato/i in una pagina.
Ecco vorrei sapere se il mio ragionamento per la creazione di una db e quindi di tabelle è corretto.

I contenuti di alcune tabelle saranno gestiti da colleghi, che inseriranno degli articoli testuali.
Stavo pensando che, per ogni tabella dovrei prevedere un campo "chiavi_di_ricerca " con all'interno un minimo di 5-6 parole che, descrivono appunto il contenuto inserito.

Cosi che al momento della ricerca, digiterò nella casella di ricerca "parola" e eseguirò una select su tutte quelle tabelle che hanno il campo "chiavi_di_ricerca", per estrapolare tutti i record che hanno quella "parola".

Secondo voi è una strada percorribile oppure no?
Aiutatemi per favore.
Grazie e buona giornata.

[franzauker2.0]

Lo è se le fullscan necessarie per le ricerche non sono proibitive.
Altrimenti tocca usare qualcosa di più sofisticato, tipo sphinx

[ANTAGONIA]

grazie della risposta, ma non c'ho capito nulla
quando dici:"Lo è se le fullscan necessarie per le ricerche non sono proibitive."
cosa intendi?
grazie mille

[bomberdini]

Ciao,

Puo andare come idea se riesci a "calibrare" bene il campo "chiavi_di_ricerca".

E per calibrare bene intendo che non sia ambiguo...

[franzauker2.0]

Originariamente inviato da ANTAGONIA
grazie della risposta, ma non c'ho capito nulla
quando dici:"Lo è se le fullscan necessarie per le ricerche non sono proibitive."
cosa intendi?
grazie mille

Associare delle tag alle righe (perchè questo sono) consiste nel memorizzare in un campo di testo una o più tag.
Finqui nulla di male, tipo "gatti gelato berlusconi" piuttosto che "berlusconi amichette soldi" e così via.
Quando vai a cercare però "berlusconi", ad esempio, dovrai dare qualcosa tipo
select ... from tabella where tag like '%berlusconi%'
Qui casca l'asino, perchè la ricerca del tipo %like% richiede che venga fatta una full scan, ovvero lettura di ogni riga della tabella e ricerca della sottostringa.

Non ci sono ottimizzazioni dovute all'uso di indici (anzi, in questo caso sono negativi addirittura).

Durante la full scan accadono tante cose brutte: il server si deve leggere l'intera tabella, riga per riga (per la precisione pagina per pagina, a seconda dell'engine utilizzato) e, soprattutto, deve mettere dei lock in lettura sulla tabella medesima.
Questi possono essere addirittura a livello di tabella (=blocca tutte le scritture) se usi myisam.
Traduzione: mentre l'utente X cerca "berlusconi" l'utente Y NON PUO' aggiornare la tabella, è "paralizzato".
Se ci sono tanti utenti che lanciano tante ricerche, e altri che vogliono scriverci sopra, allora puoi avere prestazioni bassissime dovute ai continui contendimenti delle risorse.

Se la tabella è molto grande (diciamo un milione di righe) una full scan puoi "pagarla" anche un 30 secondi.
Ad ogni ricerca "tutto" si blocca per 30 secondi (nota: questo è uno dei tipici problemi del "cerca" nei forum)

Se la tabella è piccola si utilizza, tipicamente per mysql, un tipo particolare di indice detto full text, che però funziona solo con myisam (*** nota ciò non è più vero per le ultimissime versioni, ma difficilmente li trovi nei provider).

Se usi engine con lock a livello di riga (es. innodb) allora il problema della concorrenza è (un pochino) mitigato, ma non puoi usare indici (come detto ***) e quindi son sempre full scan.

Se le tabelle son piccole invece non ci sono grossi problemi: come sempre il "dramma" lo vedi quando esci dalla prima parte simil-lineare in prossimità dello zero e inizi a pagare i tempi polinomiali - qui si apre tutto un mondo sulla derivata lasciamo stare -

Cosa si fa quindi per implementare un "gugle" per un database mysql? Si fa come hai messo, ovvero con un campo TAG con tante belle parole, e poi usi uno strumento "a parte", che poi sono due, sphinx e lucene, per effettuare le ricerche.
Lucene è del mondo JAVA e per ora lo lascio stare.
Sphinx invece è più del mondo PHP/C, e in sostanza è un accrocchio esterno che crea degli indici specializzati per i tuoi campi TAG (e tutti quelli che vuoi, in realtà).
Poi quando vuoi fare un'interrogazione non dirai
select * from tabella where tag like '%berlusconi%', bensì

"caro sphinx ritornami tutte le chiavi di tutti i record che contengono 'berlusconi' e magari facci il group_concat
Poi, caro mysql, dammi tutte le righe che hanno le chiavi IN il group_concat precedente"
Siccome mysql è molto veloce nella ricerca di righe con uguaglianze, quindi con indice, e che è molto veloce (anche nelle versioni più vecchie) per le ricerche IN (elenco fisso), che viene addirittura quicksortato, con questo metodo puoi fare un "gugla" su un milione di righe in una decina di millisecondi (sono dati realistici, li faccio tutti i giorni)

Però devi "pagare" la gestione dell'indice sphinx, il quale richiede una full scan (rigenerazione dell'indice) che, e fatta da zero e pianificata, sempre per un milione di righe, può richiedere diciamo un minuto.
(** esistono gli indici sphinx delta ma ti confesso che sono una tale rottura di @@ che neppure io li uso).

Risultato? Pianifichi un aggiornamento dell'indice, poniamo una volta all'ora,e quindi hai il db paralizzato per un minuto ogni ora.
Ovviamente non potrai trovare i nuovi dati finquando l'indice non sarà rigenerato.

Poi c'è da dire che mentre per mysql sphinx è un modulo "esterno" (** in realtà puoi compilare una versione di mysql speciale con una sorta di integrazione), per mariadb lo è molto meno, nel senso che è più facile utilizzare query "miste", come se sphinx sia "quasi" parte di mysql.

E' solo un'introduzione, ma è notorio che non sono molto esperto di queste cose, quindi dovrai accontentarti

[franzauker2.0]

Originariamente inviato da bomberdini
Ciao,

Puo andare come idea se riesci a "calibrare" bene il campo "chiavi_di_ricerca".

E per calibrare bene intendo che non sia ambiguo...

[bomberdini]

Originariamente inviato da franzauker2.0
è notorio che non sono molto esperto di queste cose

CONFERMO... Datti all'ippica

[franzauker2.0]

Originariamente inviato da bomberdini
CONFERMO... Datti all'ippica

Mi dò alla "gattistica", se non ti spiace.

[bomberdini]

Meglio ancora... e raccontagli anche come e' nato mysql e tutta la storia degli avi

[franzauker2.0]

Originariamente inviato da bomberdini
Meglio ancora... e raccontagli anche come e' nato mysql e tutta la storia degli avi

Sono un po' confuso.
Se dò la soluzione tout court, ontologicamente la migliore possibile, divento saccente.

Se spiego invece, sia pure a livello adatto per un principiante, perchè e percome si fa qualcosa, non va bene lo stesso, nonostante siano consulenze che si pagano, tipicamente, migliaia di euro.

Bon, c'è una terza scelta, e penso che la rispolvererò.
Ossia