Inserting Active Directory data into the database

  • Hi Gurus,

    I wanted to run some ideas by you and see if I can get your thoughts on it.

    We are building .net app that points to Active Directory, grabs some employee info such as Firstname, lastname, title, email, address, city, state, zip and populates the boxes with these attributes.

    We are also populating a dropdown box with lists of Supervisors who approve certain documents.

    Finally, we are populating a dropdownbox with lists of Department Heads who have the final say on approved documents.

    From the screen design perspective, all is well.

    My doubt is how to design the db.

    Should all the data be stored into one table?

    Or should they be broken up into perhaps 3 or 4 tables?

    I would be glad to provide additional info if needed.

    Thanks alot for your assistance.

  • That depends on what you're keeping in the database, and what you plan to do with it.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • I think we need a lot more info than what has been provided to assist in db design questions such as this.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Thanks good people for your prompt responses.

    Ok, let me see what additional information I can provide.

    The form is divided into 4 sections.

    The first section collects Requestor (the employee making a certain request) information.

    As stated, demographic information such as Name that that is auto filled by the requestor, there is also another box called OtherName. The box is provided just in case the employee filling out this form is not the same as the employee who would be using the approved request.

    Then date of request, emp department, office#, employee title, email, phone, work address, city, state, zip code.

    Section 2 called Remote Access contains the various requests the users is trying to make.

    For instance, Remote Access as sub header to get into company domain from outside. This comes with 3 radio button choices.

    Operating System as anothe sub header with radio button options to choose which operating system to install.

    Then under this section, is Remote PC as sub header with 2 radio buttons to work with Desktop or laptop.

    Also, under this section is sub header called Priority with 2 radio buttons: urgent or normal.

    Finally, Comment box to justify why the request is being made, followed by request for employee's PC and what areas to get into like email, hostname, etc

    Section 3 is Supervisor approval.

    This section has dropdown of supervisor lists dynamically populated from Active Directory and Date the info provided is needed.

    Final section which is Section 4 contains a dropdown list of 4 emp who act as Department heads authorized to print out document write final approval signature.

    We will definitely will be needing an id or something that will track when each section is completed.

    For instance, when the requestor submits the form, and the Supervisor receives an email with a link to the form, the information completed by requestor should be grayed out and made un-editable by the sub sequent approvers.

    We will handle the disabling on the frontend but we will something to use to trigger our code to work.

    I hope I have not provided more than I am asked.

    If so, please forgive me.

  • I would think you'd have one table with the request information, including who made the request, the details of it, and when it was made; who approved it, and when; and who gave final authorization, and when.

    If the requests also have a reject option (I'm assuming they do), then you might want to move the who/when data to a status log, out of the actual request data. Then it can go back and forth as needed, till approved or finally disapproved-and-stop-asking, or whatever else would terminate the workflow.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply