Need to finalize the database design for all specifications. I do believe Ignace has started on some of this on the development forums for one of the specs. However, we'll need to do this for all of the specifications.
@ignace - do you think it makes sense to continue on this while @trq works on the view stuff for proem?
@misterphilip, we need to catch up in irc. I'm really starting to think we might need to go down a different path.
I seriously have no time on my hands at the moment after going back to work.
Wrong @philip, I think you mean @MisterPhilip ... I received an email and wondered "What did I agree to do this time?" :)
Ha, sorry @Philip - too many of us Philip's in the world ;)
@trq - yeah, if we need to switch back to sf2, that's fine. I know @gizmola would be happy.
Okay, just talked with @trq. We'll use sf2 for the project now, since he might not have enough time to work on proem for our uses.
Ok, so it seems we need to figure out a naming strategy.
I put in a vote for the _'s where necessary and all lowercase names.
As far as the primary ID, I prefer it to just be id, but we just need to figure out having it as table_id or just id. Voice your opinion, and once we have the basic naming strategy laid out, we can more effectively work on creating the structures.
I'm used to running it as table_id, but I'm fine with not here. As long as any FK's have the table name in front of them, I'm fine with it. (see example below)
user_id (references user.id)
I would like to adhere to some standard but I am finding it hard to locate a decent SQL writing standard that people use.
So yea, let's go with id for the primary key and then any foreign keys need the table_id. Unless there is a valid argument and or an actual document we can go by and adhere to, that is what we will stick to.
Bump to see if anyone has had time to make any progress on this...