Re: DB Schema

[Thomas Wood <thos gnome org>]

On 04/06/07 23:08, Bruno Santos wrote:
> On Jun 4, 2007, at 8:47 PM, Thomas Wood wrote:
[...]
> > Artwork:
> >   Missing a name field?
> >   What is the allow_in_collection field for?
> >   What is download_id?
> >
> > Collection:
> >   What is download_id?
> >   Missing a name field?
> Both the download_id in Artwork and Collection where suppose to 
> represent the file associated with them, but now that I think of, it is 
> better to have a field in download table to associate it with the 
> artwork and other to associate it with the collection.

Yes, downloads should be a one to many relationship with respect to 
artworks. That is, one artwork may have many downloads (e.g. different 
wallpaper resolutions).

> And yeah, a name field is missing in both.
>
> The allow_in_collection field is suppose to represent if the author of 
> the work allows it to be used in the construction of a collection. I 
> think authors should say if they want their works to be used in 
> collections.

OK, although sounds a bit strange to me. Wouldn't the license indicate 
this anyway?

> > Downloads:
> >   Do we need an extra field here for file type, or size?
>     We can add both fields, and during the submission fill in that 
> information.
> >   Should we calculate the resolution from the file, rather than have a 
> > fixed number of resolutions?
>     Ok, we can do that, but I still think we should have a list of 
> resolutions, in case we want to do a search of wallpapers by resolution.

Yes, definitely. The only danger with reading the information from the 
file is that the file itself may not be accurate. For example, the file 
may be 1025x769 rather than 1024x768.

> > Types:
> >   Install instructions would be good here
> True, that's why FAQ's have an type_id associated.
> I also thought categorize FAQ's. Doing so we can have a category for 
> each work type.

Great! This occurred to me too when I saw the type_id in FAQ.

> > Categories:
> >   What are the values for flag?
> The only job I predicted to this flag was to say if that category was a 
> contest or not. We can represent it like 0:not contest; 1:contest.
> But in case some other idea comes up, we can define new flags to 
> represent new options.

Sounds reasonable.

[...]
> > We also need to decide on a naming convention for our table and field 
> > names. There are some good ones on the internet. I have found 
> > <http://justinsomnia.org/writings/naming_conventions.html> which is 
> > probably closest to our current style. It also lists some alternatives 
> > at the bottom. Let me know which one you like best.
> I like the one in the link.
> There just one thing I would prefer to use: field naming.
> It says we should name fields like  <table_name>_field   i.e. product_name
> I prefer to use just name, since I queries we can use product.name to 
> refer to that field.
>
> What do you think?

As long as we have a style and stick to it then it is fine with me.

Regards,

Thomas