![]() |
|
![]() |
|
|
Thread Tools | Display Modes |
|
|
#11 |
|
Programmer
Join Date: Aug 2005
Location: Leeds - UK
Posts: 69
Rep Power: 4
![]() |
But is
activity(activityLog,userName,time,page) normailised? activityLog is the uniqueID for an instance of an activity. This table would allow me to output something like, user JIM BOB accessed CREATE CUSTOMER ACCOUNT on 1/1/07 at 7.30am. Which is brilliant, but what are your thoughts on the table integ? For example, the table may contain repeating groups; 1 Jim 1/1/2006 editCustomer 2 Bil 2/1/2006 createAccount 3 Jim 3/1/2006 createUser Here Jim is repeating - is this ok or should i create another table?? Kinda stuck on this...any sugg? Thanks in advance as always |
|
|
|
|
|
#12 | |
|
Resident Grouch
![]() ![]() ![]() ![]() ![]() ![]() Join Date: Jun 2005
Posts: 6,453
Rep Power: 10
![]() |
Quote:
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.
__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers |
|
|
|
|
|
|
#13 |
|
Programmer
Join Date: Aug 2005
Location: Leeds - UK
Posts: 69
Rep Power: 4
![]() |
Thanks DeWei, ok so i was kinda worrying about not much >.<
I think the whole gvnmnt farming thing mighta been wastred on me lol |
|
|
|
|
|
#14 |
|
Resident Grouch
![]() ![]() ![]() ![]() ![]() ![]() Join Date: Jun 2005
Posts: 6,453
Rep Power: 10
![]() |
Jes' make yer activity table 3 fields wide (ID, User ID, Activity/Activity ID); if it gets to be a mile long, no harm done
. Post back if you have more problems.
__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers |
|
|
|
![]() |
| Bookmarks |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
| Display Modes | |
|
|