Re: [Sqlgrey-users] Re: sqlgrey easier data mining

[Lionel B. <lio...@bo...>]

Michel Bouissou wrote the following on 02/05/05 10:09 :

>Le Vendredi 04 F=E9vrier 2005 21:18, Lionel Bouton a =E9crit :
> =20
>
>>Seems to be a good thing to have, especially since it will be a small
>>column that shouldn't put much stress on the database. Added to my TODO=
.
>>
>>   =20
>>
>>>2. Addition: client_name
>>>     =20
>>>
>>I'm afraid this won't be so easy :
>>- in the default 'smart' mode, most of the entries aren't IP address bu=
t
>>class C networks.
>>- a VARCHAR column with potentially very long names is not a welcomed
>>addition : it could hurt performance badly.
>>   =20
>>
>
>I would vote YES for "first_seen" and "counter" columns
>

I see the need for a first_seen : logs are mostly useless for this=20
information.

counters : what for ? As I previously said, I'm not sure they will be=20
usefull as logs already hold more relevant information. It will hurt the=20
performance of people willing to use them too (if I make them optionnal=20
as requested) as this will need an update to the database on each and=20
every mail SQLgrey will see (db updates are slow...).
If someone tells me what it will be used for that can't be done with a=20
simple log parsing tool, I'd be more inclined to put it in my TODO list.=20
In the other case, I'll add a logparsing tool in the TODO...

> in "awl" tables, and I=20
>would vote NO for "client_name".
>
>Not only "client_name" would be meaningless for all the class-C records,=
 but=20
>also a reverse DNS entry is something that can change over time. If we p=
ut a=20
>client_name column, we should update it with the client_name Postfix giv=
es=20
>everytime we update a record. (note that we could very well put there th=
e=20
>last client_name seen even when we use a class-C entry type, as this wou=
ld=20
>still give an indication about the calling client).
>But I'm not sure that having this in the tables would be very useful.
>
> =20
>

Agreed.

>I would also vote YES for having the same field name for the IP in all t=
he=20
>tables.
>
>Adding columns to the tables rises the issue of upgrading : When upgradi=
ng=20
>from an oder version to a version with new columns, should the new colum=
ns be=20
>initialized with arbitrary blank/zero or "today" values, or completely d=
rop=20
>the existing tables and let them rebuild by themselves from scratch with=
 new,=20
>real data ?
>
> =20
>

For first_seen, my plan is to make the update process set them to last_se=
en.
If counters are really needed, they will be set to 0.

Lionel.