This project has begun!
View Single Post
12-29-2008, 07:04 PM
Join Date: Apr 2007
Originally Posted by
Err... I think the database should be more dynamic. In other words: be able to change to work seamlessly with Vbulletin, PHPBB, SMF, etc.
Feel free to quote me on this later, but I think that would be a huge waste of time and effort. If it comes to it, later (much, much later) we could build some bridges between our application and other applications but I don't see it as an essential, or even useful, thing to work towards right now.
Other SQL comments:
For the primary keys, use unsigned ints. Why allow for, but never use, numbers from -2147483648 to zero?
users.user_pass doesn't need to be VARCHAR(255). Depending on what hashing we'll be using, it can be CHAR(32) or something like that.
It might be worth making item_comments.item_comment_text bigger, 255 chars might seem more than enough (cf. Twitter's 140 limit) but should we really rule out those commenters who like to write long, thought-out messages?
Maybe I'm just being blind, but I don't see a common key between the items and item_comments tables.
Perhaps consolidate multiple tables. A subscription is a subscription, why have two tables for essentially the same thing? If we later want to allow many different kinds of subscriptions (follow comments for a user, item, album, new items from a user, in a album or gallery...) would we need a new table for each of those? The same goes for the *_comments tables.
Standardise the naming. Some tables are plural, others not. Some columns underscore-delimited while others mix with camelcase. Personally I'd drop the table name prefixes for the columns too:
Sorry for being so nitpicky!
View Public Profile
Send a private message to Salathe
Visit Salathe's homepage!
Find More Posts by Salathe