Query con LIKE e db di grandi dimensioni

[GianfrancoPa]

Ve ne sarete accorti, da qualche giorno ho iniziato ad usare i database... altra domanda:

nel mio db al momento ci sono circa 30.000 record, di cui uno è del tipo char(8) e contiene date, ad esempio: "12/12/12".

Per effettuare ricerche utilizzo nelle query la funzione LIKE, del tipo "%/12/12".

Ho notato che nel restituire tali query ci mette tantissimo tempo, e infatti ho letto in rete che LIKE ha proprio questo difetto.

Se utilizzassi al posto della variabile char(8) tre tinyint, effettuando quindi ricerche esatte senza l'utilizzo di LIKE, secondo voi otterrei grandi miglioramenti??

Grazie mille per la pazienza!

[optime]

perché per le date non usi il tipo data?

[GianfrancoPa]

E'un database di cui ho "ereditato" il progetto e adesso mi trovo a dover fare queste ottimizzazioni.

In realtà i campi sono due char(8), uno per la data (tipo "12/12/12") e l'altro per l'orario ("tipo 10:13:45).

Non avevo pensato ad usare il campo date e forse, nel mio caso, dovrei usare datetime che occupa 8bye, oppure usare separatamente date e time che complessivamente occupano 6 byte? considerndo la dimensione del database, occupare meno spazio è fondamentale...

In ogni caso nella gestione di questi tipi di variabile acquisterei velocità rispetto all'utilizzo della funzione LIKE?

[optime]

devi deciderti tra spazio e performance. se li vuoi tutti e due da qualche parte devi piangere. poi complimenti per l'esempio! 12/12/12!!!! così si capisce bene quale è l'anno, quale il mese e quale il giorno

[GianfrancoPa]

ahah, nemmeno a farlo apposta!! Cmq gg/mm/aa.

Se per avere una migliore performance devo sacrificare 2 byte ci può stare!!! Quindi, qual è la soluzione migliore secondo voi???

[optime]

1. se vuoi restare in modalità testo, almeno gira le date in modo da avere aa/mm/gg (oppure aaaammgg) così stanno "naturalmente" in ordine
2. invece della LIKE (dato che sono SEMPRE otto cifre) puoi fare ... WHERE SUBSTRING(data,1,6)='201301' per avere gennaio di quest'anno
3. un formato Date sarebbe più appropriato

alla fine, prova un po' di tutto e vedi cosa è meglio per te

[franzauker2.0]

Bhè la risposta è un po' articolata, e dipende anche abbastanza dal database che usi e dall'hardware, oltre che dalla tipologia di accesso ed utilizzo del db (in particolare concorrenza e relativi lock)
Fermo che, in generale, farsi le seghe mentali per 2 byte non è che abbia un gran senso (se usi innodb per mysql ad esempio si lavora a pagine), anche perchè considerato che in generale l'hardware odierno supporta tranquillamente lo SPAZIO, meno le complessità polinomiali (traduzione: è facile aumentare lo spazio libero, mentre tipicamente è costoso fare join)...

... vuoi usare =, like INIZIO%, like FINE%, o like %QUALCOSA%

sono situazioni diverse

[GianfrancoPa]

Uso il database di Aruba, non saprei dire altro...

Per 2 byte non ho problemi, piuttosto non saprei qual è l'approccio che consente una velocità migliore....

[optime]

se nella colonna metti le date, usa un tipo data.

[franzauker2.0]

Originariamente inviato da optime
se nella colonna metti le date, usa un tipo data.

Certamente è il consiglio più sensato.
Lo "espando" leggermente con un'ulteriore considerazione.
Se proprio sei costretto a tenerti l'applicazione così (perchè se, ovviamente, cambi il tipo del campo dovrai cambiare l'applicazione) puoi anche (superbrutalmente, è un accrocchio veramente triste) semplicemente aggiungere il campo data (al database) e magari mettere un trigger che lo aggiorna (ancora più triste).
In tal modo ti basta cambiare l'order by col nuovo campo "fantasma".

Certamente non è un granchè pulito nè elegante, tuttavia è una strada percorribile con modifiche minime al programma (e quindi lavorando sul db)