Re: cvs: pearweb /sql downloads.sql

On Tue, 2002-01-29 at 14:53, Martin Jansen wrote: > On 28 Jan 2002 23:05:43 +0100, Stig S. Bakken wrote: > > >On Mon, 2002-01-28 at 17:12, Martin Jansen wrote: > >> On 27 Jan 2002 20:31:23 +0100, Stig S. Bakken wrote: > >> > >> >On Sun, 2002-01-27 at 10:39, Martin Jansen wrote: > >> >> mj Sun Jan 27 04:39:44 2002 EDT > >> >> > >> >> Modified files: > >> >> /pearweb/sql downloads.sql > >> >> Log: > >> >> * Nuke un-necessary fields. > >> >> > >> >> > >> >> Index: pearweb/sql/downloads.sql > >> >> diff -u pearweb/sql/downloads.sql:1.1 pearweb/sql/downloads.sql:1.2 > >> >> --- pearweb/sql/downloads.sql:1.1 Fri Dec 21 23:41:18 2001 > >> >> +++ pearweb/sql/downloads.sql Sun Jan 27 04:39:44 2002 > >> >> @@ -3,8 +3,6 @@ > >> >> file INTEGER NOT NULL, -- REFERENCES files(id), > >> >> package INTEGER NOT NULL, -- REFERENCES packages(id), > >> >> release INTEGER NOT NULL, -- REFERENCES releases(id), > >> >> - author INTEGER NOT NULL, -- REFERENCES users(id), > >> >> - category INTEGER NOT NULL, -- REFERENCES categories(id), > >> >> dl_when DATETIME NOT NULL, > >> >> dl_who VARCHAR(20), > >> >> dl_host VARCHAR(100), > >> > > >> >Heey, please revert this patch. These are for making download stats per > >> >author and category, obviously. > >> > >> Storing the author id with the download log is a bad idea because > >> there can be multiple authors of one package and the author field > >> can only take _one_ of them as it's value. > >> > >> I suggest we drop this field and solve the author statistics > >> via some joins in the download stats. > > > >I was thinking about having a single row for each author, but maybe > >that's overkill? How much do we want author stats? > > May be I don't understand your sentence completely, but what > I want to say is: > > If we have a single row in the downloads table for each author, > we will soon end up in sth. like this: > > Package X has 3 maintainers. If one downloads the package, we > need to insert 3 entries in the downloads table, because > every maintainer has to be mentioned in the author field. Finally > this results in 3 entries that also stand for 3 downloads, which > is actually wrong! I was thinking more about adding rows with just the author set (and package, release etc. set to NULL) for number 2 and up. > My suggestion is to drop the author field in the downloads > table and to generate the author stats via some lookups > across the packages, releases and downloads table. >  > I hope you understand, what I want to express. (Sorry for > my sometimes poor english.) The loss here is of course that the current authors get all the download credit from older authors. Maybe the downloads table needs some rethinking? - Stig