Database Design: member registration

  • 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

  • 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 Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • 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 😀

  • 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 Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • 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