I also log how many hits they got from their search. That tells us if
our search mechanisms are working or not.
Jerry Johnson wrote:
> Yes, but the rows are not (duplicate).
>
> The time, the search string. Potentially the IP address. in
> combination, always unique.
>
> On 8/24/07, stylo stylo <
> Yes, but the rows are not (duplicate).
>
> The time, the search string. Potentially the IP address. in
> combination, always unique.
>
Well, I just meant a duplicate term meaning after a year you'd have some insane
number of rows.
Thanks.
~~~
Yes, but the rows are not (duplicate).
The time, the search string. Potentially the IP address. in
combination, always unique.
On 8/24/07, stylo stylo <[EMAIL PROTECTED]> wrote:
> You seriously just keep adding row upon (duplicate) row every day for years
> and years? That's a hell of a lot of r
You seriously just keep adding row upon (duplicate) row every day for years and
years? That's a hell of a lot of rows because people search a lot. I'm
surprised, but I'm no expert. If no one thinks that's a bad idea...
Thanks again.
~
Just have one table, do not worry about the size of the table, it's
negligible. If it's a site that requires a login, save their login id,
the search term and the date (it does not matter if you intend on
using it now, you might later). You do not need a counter, you can
count using the SQL query.
>Actually, I wrote an article about this for CFDJ, which includes code for a
>cfc that reports on search terms, auto-mails a weekly (or other period)
>report, etc.:
>
>http://cfdj.sys-con.com/read/48234.htm
I'll take a look, thanks for the tip!
~~
>Create two data tables, one for terms (have an term_ID and search_term
>field) and one for search date/time (have a term_ID and date/time field).
I know little about db design, sorry: why would you use 2 tables rather than
one with 3 columns?
>>Sure it's helpful. I want to know how many times p
Actually, I wrote an article about this for CFDJ, which includes code for a
cfc that reports on search terms, auto-mails a weekly (or other period)
report, etc.:
http://cfdj.sys-con.com/read/48234.htm
I hope this of interest,
James Edmunds
On 8/23/07, stylo stylo <[EMAIL PROTECTED]> wrote:
>
>
In my mind, logfiles should be lean, simple and fast. no thought, just
entry. Write only. Just the facts, ma'am
Once the data goes in, reporting from it is a different matter.
queries, olap apps, and any rolled up or calculated data happen during
a different process.
Thoughts?
Jerry
On 8/23/07,
>>> I just log the term and the date. So one row per search.
I've been asked to come up with a similar function for a book database
so as to be able to sort search results by "top X". After the initial
search is run, if somebody clicks on a particular title to see the
details, it gets a "vote".
Create two data tables, one for terms (have an term_ID and search_term
field) and one for search date/time (have a term_ID and date/time field).
In the terms table check to see if the term is there. If it is get the
term_ID and update the time table with the term_ID and date. If it is new,
add the
Sure it's helpful. I want to know how many times people search for
terms as it helps me figure out what people are searching for. Having
times also is important. Ajax may be super important this year, but
may fall next year.
On 8/23/07, stylo stylo <[EMAIL PROTECTED]> wrote:
> >I just log the term
If you split multiple search terms on a single search up into multiple inserts
(ie; "my best dog" would result in three inserts) then you could do a COUNT(*)
AS C and a GROUP BY TERM, ORDER BY C DESC, TERM or something like that.
That'll do yer.
BTW, if you want to be extra sneaky, if the site
>I just log the term and the date. So one row per search. This then
>lets me do stuf like top ten search phrases.
Wouldn't you need to search for the phrase first and increment a total?
Otherwise you'd have "naked" on 90,000 rows :-) And the date only refers to the
last time, so not so helpful,
That's what databases are for tho.. to be 'quite big' ;). We have
tables that have hundreds of millions rows. And as long as they're
properly indexed (partitioned is super nice too) they'll fly. Don't
worry about having a big db table, unless you're limited on space in
the DB.
On 8/23/07, Raymond
I just log the term and the date. So one row per search. This then
lets me do stuf like top ten search phrases.
On 8/23/07, stylo stylo <[EMAIL PROTECTED]> wrote:
> Any suggestions on how best to store search terms entered on a website?
>
> If the database, then see if used already and increment,
Any suggestions on how best to store search terms entered on a website?
If the database, then see if used already and increment, or add if not, and
maybe set a datelastused? But then that is 2 db hits right there and could grow
quite big.
Or just write them to a file and parse and reset the wh
17 matches
Mail list logo
