February 19, 2008 at 12:21 am
I'm really new for the database area. I want to implement the system that has the member system
The user should register for using system then the officer has to verify whether
that user can use this system or not. After passing the approval, the officer have to
send back the email to tell the register that he can access to system from now on
but he have to activate his account before doing the transaction.
The system is something like above. My question is I design to have the group of table
that keep the record of transaction of the member. But I have no idea to design how the register
data will be kept.
The register have many kinds that have different data to collect, some just require only student ID
some have to fill in his profile by himself
and after those registers is approval to be member, they have to be classified like the time they register
I wonder how good if I duplicate the set of tables for member profile and register profile and
keep the same thing because I think the member profile should not contain some junk data.
The transaction of member will be used to generate some important report.
Any suggestion would be appriciated 🙂
Thanks in advance
February 19, 2008 at 5:31 am
If I understand the question correctly, no I wouldn't duplicate the structures & move the data around. Instead, store the member data in whatever format you had planned. Inlcude a table that will store the status of the member data. Note, a table, not a column in the member table. This way, you can insert member status to the table and have a record over time of how that member's status changed. I'd also have a table for storing the Admin's communications to the member, again, a seperate table, that you can insert each of the Admin's communications to.
I'm not sure I can be much more specific based on the requirements you described. Others might help more.
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
February 19, 2008 at 7:12 am
You means when the register sign up, data will be kept in the member table right?
Actually, my wonder is.. the data in member table is quite important so I don't want to keep data that
some register may enter garbage in the member table.
I just want only the approved member's data will be stored.
ps: I'm not good at english, sorry if you may confuse my words
Thank you for your kindness 😀
February 19, 2008 at 8:14 am
Yeah, I wouldn't create two data structures for the same data. I'd store the "messy" data right along side the "approved" data but then simply have a clean-up process that gets rid of data that is not approved. After all, as long as you know that you can limit the select statements to only return either the unapproved or approved data, it doesn't matter that it is stored in the same location since no one should be seeing anyone else's data.
Agin though, honest people can disagree. I actually have a system where we're storing financial data twice. The first is the inprocess, unbooked, "messy" data, stored in one schema. Next to it is an identical set of tables, in another schema, that represents the actual data sent to billing. We did this because we can't "clean up" billed data. No deletes allowed. But we had to have a mechanism for storing the data temporarily while it was determined if it was clean or not. Once it was determined to be good data, a process sends it out to billing and moves it between schema's, deleting the in process data. If, on the other hand, the data was determined to be incorrect, we can clean it right out of the inprocess data, no muss no fuss. I wouldn't have done it that way if it was not financial data because it means I have to maintain the exact same structure, twice. It's a pain in the bottom.
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
February 22, 2008 at 8:32 am
Thank you very much, Grant Fritchey
You give me a very good explaination, I really understand your example and your reason. :w00t:
I'll adapt your idea to my work.
THANKS AGAIN
😛
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply