On Sun, Aug 23, 2009 at 02:36:44AM -0500, Cristian Gómez wrote: >I made this Classes diagram [1] in DIA to make the basis for the development >of the site. It's really basic but I think that it's a start point.
I put my two cents in another message but I'll put some cents here too :) >I'll explain several points to make the diagram clear: >* The classes have the attributes that I can figure out from the requests on >this thread. Sure, whatever. >* A user can be a maintainer of a distribution/application or just a regular >user (someone with account in the page who can vote for the distros/apps >popularity) I like it; a user is a user, the attributes are attributes. >* The "File" class (table) contains the files (commonly image files) of the >three entities: distros/apps (screenshots); user (user image) >* The distros and the apps have an attribute to represent their popularity >(a float number from 1 to 5) that is set with a stored procedure that update >the "popularity" field with the average of the califications of the users >for the distro/application (a user only can vote once for an distro/app, >which makes the popularity more reliable). The procedure is triggered >whenever an user give a distro/app application) Denormalization techniques are better for sites that take a lot of hits and don't want to calculate aggregates on every request, because they are read much more than written to. I think the moko application db will never be popular enough to benefit from this, and having stored procs can clutter the code. >TODO>I don't know if the diagram is usable/compatible with the apt-portal idea >but is my way to bring my two cents for the cause...... I haven't had time to look at apt-portal yet, and I don't know if anyone yet has, but we'll see.. :) Thanks! -- mjt _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community