Stephen is definately right about the design of your
database. Creating a table for each person would make
management cumbersome for you.

-Ev72178


--- Stephen Moretti <[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] wrote:
> 
> >I am creating the databases in Access, and
> basically need a detail page on  
> >every person on the database. An online resume if
> you like. So that their 
> >resume  can be updated. Now, should I create (if it
> is possible) an expression that will  create a new
> table for each person, or should I put everything in
> one 
> >big  table.
> > 
> >I guess it would be easier to manage in seperate
> tables, and that would  
> >definitely help with the infinite number of records
> I may need on every person  on the database. But can
> new tables be automatically created when new records
>  
> >are added to the original database.
> > 
> >Does anyone know a good way to do this?
> >
> You definately do not want to be creating a table
> for each user.  If you 
> have 5 people "register" then you'd end up with 5
> tables.  If you have 
> 50,000 people register, then you'd end up with
> 50,000 tables and you 
> definately do not want that.
> 
> Whistle stop introduction to designing databases :
> =================================
> Look at the data you want to store, say a form made
> of one or more pages 
> that someone will be filling in.
> 
> Your main table in the database will be for the
> items on the form that 
> only appear once.
> 
> Any repeated items will have their own tables. For
> example, in your 
> case, a person can have had multiple jobs, so you
> would have a "job" 
> table as well as an "applicant" table.
> 
> To link the main table to any repeated items you'll
> need to have a 
> unique identifier from your main table in your
> repeated item tables eg.  
> your Applicant table has an autonumber field call
> ApplicantID.  Your 
> "Job" table will have an autonumber field, say
> JobID, to give each 
> record in the Job table a unique identifier, but
> also in Job will be a 
> Foreign key field called "ApplicantID". This foriegn
> key will contain 
> the autonumber assigned to the Applicant when it is
> inserted into the 
> database, so that you can tell which jobs belong to
> which applicant.
> 
> Applicant
> =======
>     ApplicantID
>     Salutation
>     FirstName
>     Initials
>     Surname
>     DateOfBirth
>     Address1
>     Address2
>     Address3
>     Town
>     County
>     Postcode
>     Country
>     TelNo
>     MobileNo
>     EmailAddress
> 
> Job
> ===
>     JobID
>     ApplicantID
>     CompanyName
>     JobTitle
>     JobDescription
>     StartDate
>     EndDate
> 
> Every applicant would get one row in your Applicant
> table and zero or 
> more rows in your Job table, depending on how many
> past jobs they have 
> had and put into their application.
> 
> And thats it!  Well not really..... This barely
> scrapes the surface of 
> good database design, but it will give you a rough
> idea of how to create 
> simple databases.
> 
> Hope that helps.
> 
> Regards
> 
> Stephen
> 
> 
>


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support 
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49

Message: http://www.houseoffusion.com/lists.cfm/link=i:15:1173
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/15
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:15
Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.15
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Reply via email to