Hi there. As you will see from my questions, I am an SQL newb. I
dabble but never get to spend enough time to get proficient so base any
feeedback on that basis please. This is all theoretical information at
this point so I am also going to post this in a MySQL related group. I
will create some designs and post back to the group if I get any
feedback I can use.

Problem:

I would like to be able to keep a running percentage total in a field
associated with my users. In order to calculate the totals, I will
parsing a text file with entries from my users in it. The parser (AWK
etc) will search the file for specific text, compare it to information
in another file and output some entries into a csv file which can
subsequently be imported into the database.

The users make posts that are considered good and bad and the rating
percentage must be based on that. For example, if a user makes 10
posts in a day, and 4 of them are considered 'bad' by my criterion, the
rating should reflect a score of 60% for that day.

However, the rating is an ongoing value that will be adjusted daily and
I must maintain a running total against all previous posts. So, lets
say on day two the same user posts 10 more times and 3 are 'bad', I
must adjust his score to reflect a total percentage rating which would
then be 20 posts with 7 being bad for an overall rating of 65% etc.

My question is, how should I go about recording and calculating all
this information?

Here are my thoughts. I have a users table with a field called
something like 'Rating' which stores the overall value (65% etc). This
value would have to be calculated from fields in another table like
'Posts' which records each post in 'Good' and "Bad' fields that
increment. The Good and Bad fields would be incremented (populated)
from the text that gets imported etc.

Looking for thoughts from experienced db designers please. Thanks a
lot in advance for any responses.

Hi

The is a group aimed at SQL Server and therefore you may want to post in a
more appropriate forum.

When posting table definitions (DDL) and example data (in a usable form) are
always less ambiguous than a drawn out description see
http://www.aspfaq.com/etiquette.asp?id=5006 although the means of obtaining
these may be different on MySQL. You current attempt(s) and expected output
will also be a good indication of what you are trying to achieve.

I don't know enough about MySQL to post accurate examples , but assuming
your date is in a 8 character column (say formatted 'CCYYMMDD') and each
user is identified by an ID column, then the following may work (although it
may not be the fastest of solutions!):

SELECT a.id, a.date,
(SELECT COUNT(*) FROM MyData b where b.Date = a.Date and Rating = 'Bad' ) AS
TodaysBad,
(SELECT COUNT(*) FROM MyData b where b.Date = a.Date ) AS TodaysTotal,
(SELECT COUNT(*) FROM MyData b where b.Date <= a.Date and Rating = 'Bad' )
AS CumulativeBad,
(SELECT COUNT(*) FROM MyData b where b.Date <= a.Date ) AS CumulativeTotal
FROM MyDate A
WHERE A.Date = '20050827'

John


<fwells11@hotmail.com> wrote in message
news:1125084576.325630.252130@g44g2000cwa.googlegr oups.com...
> Hi there. As you will see from my questions, I am an SQL newb. I
> dabble but never get to spend enough time to get proficient so base any
> feeedback on that basis please. This is all theoretical information at
> this point so I am also going to post this in a MySQL related group. I
> will create some designs and post back to the group if I get any
> feedback I can use.
>
> Problem:
>
> I would like to be able to keep a running percentage total in a field
> associated with my users. In order to calculate the totals, I will
> parsing a text file with entries from my users in it. The parser (AWK
> etc) will search the file for specific text, compare it to information
> in another file and output some entries into a csv file which can
> subsequently be imported into the database.
>
> The users make posts that are considered good and bad and the rating
> percentage must be based on that. For example, if a user makes 10
> posts in a day, and 4 of them are considered 'bad' by my criterion, the
> rating should reflect a score of 60% for that day.
>
> However, the rating is an ongoing value that will be adjusted daily and
> I must maintain a running total against all previous posts. So, lets
> say on day two the same user posts 10 more times and 3 are 'bad', I
> must adjust his score to reflect a total percentage rating which would
> then be 20 posts with 7 being bad for an overall rating of 65% etc.
>
> My question is, how should I go about recording and calculating all
> this information?
>
> Here are my thoughts. I have a users table with a field called
> something like 'Rating' which stores the overall value (65% etc). This
> value would have to be calculated from fields in another table like
> 'Posts' which records each post in 'Good' and "Bad' fields that
> increment. The Good and Bad fields would be incremented (populated)
> from the text that gets imported etc.
>
> Looking for thoughts from experienced db designers please. Thanks a
> lot in advance for any responses.
>

On 26 Aug 2005 12:29:36 -0700, fwells11@hotmail.com wrote:

(snip)
>Problem:
>
>I would like to be able to keep a running percentage total in a field
>associated with my users.

Hi fwells11,

Don't. The basic idea of a databsae is that you don't store information
that can be computed from other information; you compute it whenever you
need it. There are exceptions to this rule (mainly performance-related),
but I don't think your case is one of them.

John already gave you a suggestion. If that doesn't work for you, then
post table structure (as CREATE TABLE statements), sample data (as
INSERT statements) and expected output and I'll see if I can help you
further (note - I can only help you with a MS SQL Server solution, as I
don't speak MySQL).

John already mentioned www.aspfaq.com/5006, so I won't repeat that.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)

Thank you John. It is going to take me some time to be able to post
some DDL info that can be expounded on. Hopefully I can post something
useful within a few days.

Thank you Hugo. The rating number will be viewed hundred, maybe
thousands of times per day. I suspect that I cannot afford the
performance hit associated with calculating the value with every page
hit. There doesn't seem to be much point to an on-the-fly calculation
if that figure only changes daily either...

In regards to having the db process my data, unfortunately the raw data
only comes in the form of huge text files. Files so large they really
need to be parsed for the information I need, compared with each other
then fed into yet another small but focused file with only the set of
information that then needs to be inserted into the db. Nothing would
make me happier than not having to deal with external data but I don't
see how I can do this any other way. Please enlighten me if you do
believe SQL server can accomplish something like this.

Hopefully I will have something more concrete to post in a few days
when I can give this some more thought and possibly throw some actual
examples of the data to the group.

Best Regards,
-Frank

On 29 Aug 2005 22:38:58 -0700, fwells11@hotmail.com wrote:

>Thank you Hugo. The rating number will be viewed hundred, maybe
>thousands of times per day. I suspect that I cannot afford the
>performance hit associated with calculating the value with every page
>hit. There doesn't seem to be much point to an on-the-fly calculation
>if that figure only changes daily either...

Hi Frank,

Sorry for the delayed reply. An illness kept me from the computer for
most of the last days.

In that case, I agree that it's better to calculate it once and store
it. But you might still have a chance to have the database do all the
dirty work.

Create a VIEW to calculate the information you needed. Make sure that
you use all the options and navigate around all the limitations of
indexed views. Then, create a clustered index on the view. This will
force SQL Server to "materialize" the view (i.e. it will execute it
once, store the results, and make sure to change the stored results when
once of the rows used in the calculation changes).

It's possible that the extra work to keep the materialized view correct
slows down the batch process for importing new data. If that's the case
for you, then you can consider dropping the view before the import and
recreating it when the import is finished.

>Hopefully I will have something more concrete to post in a few days
>when I can give this some more thought and possibly throw some actual
>examples of the data to the group.

I'm looking forward to it!

Best, Hugo

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)