Quote:
But is
activity(activityLog,userName,time,page) normailised?
|
One doesn't normalize a table, one normalizes a set.
That said, the "repeating group" thing is not a biggie, it's normal. If you're logging "activity", there is probably not any more efficient way, in the absence of specialized knowledge about the data, than to have one record for each activity. You have two fields (discounting the unique id): Actor : Activity. How can you beat that? Of course, you don't want 'Actor' to be a user record, you want it to be an ID pointing to a user record. Possibly the same with 'Activity', if 'Activity' is a thing that requires complex description. That is where normalization comes in. You can either normalize your database with traditional methods, or use more modern "design methods" that result in normalization. That's mostly quite apart from getting your application up and running as you expect it to. That's in the nature of pre-design (should have already been done) and post-design (tuning).
Consider for a moment that you decided to have one record for 'Jim". You'd have to have lebenty-zillion fields to hold Jim's activities, unless you had specialized knowledge (Jim will never do more than twenty things). Even at that, if Jim only does two things, you have wasted storage allocating for the other possible 18. If you need a spaghetti farm, you need a farm an inch wide and a mile long. If you need a microbe farm, shape doesn't matter, just total area. So buy a spaghetti farm. You can use if for whatever the government saddles you with growing.