Database Concept and Implementation

[BlackOps]

Hello,

I am very new to databases, i must create a database of employees, and their passcards. please take a look at my concept:

1.FirstName Primary key
2.LastName
3.FathersName
4.SubHolding
5.Department
6.Title
7.BirthDate
8.PassNumber
9.PassSeries
10.PassPerson
11.Country
12.City
13.Address
14.Zip
15.CardID



Magnetic Pass CARD DATA

16.CardID Primary Key
17.AreaofCoverage1 (Yes/No)
18.AreaofCoverage2 (Yes/No)
19.AreaofCoverage3 (Yes/No)
20.AreaofCoverage4 (Yes/No)
21.AreaofCoverage5 (Yes/No)
22.DayofIssue
23.MonthofIssue
24.YearofIssue
25.DayofExpire
26.MonthofExpire
27.YearofExpire

do you think it is OK?

and i plan to do it using MS Access, and write C# application which will work with it, but later database may have 50 000 records. do you think MSAccess database file and little C# application can handle it?

*database application and database file will be one ONE PC.

say me what u think guys

[dglienna]

Access does fine with 50K records, and up to 5 users, so you'll be fine with just the one. Make sure the cardid is a key in both tables so you can find the name quickly when you scan the card.

[BlackOps]

thanks for your help. I appreciate it!

and stil would like to see more opinions from you guys about my concept.. is splitting to two tables enough?

[davide++]

Hi all

First, you shouldn't define the primary key on FirstName field otherwise you cannot insert two customers with the same name. A better solution is using a specific numeric field (CUSTOMER_ID).
Then, you are defining two table with one-to-one relationship between them; one-to-one relationships are used only in special cases, and I think that this is one of them, because you split the two kind of informations into two distinct tables.
This solution works fine if a customer has only one magnetic card, but when a customer can have more than one magnetic card this design will be wrong. Maybe defining a one-to-many relationship between the two tables is a safier choose for the future.

[RickyD]

Hi all

First, you shouldn't define the primary key on FirstName field otherwise you cannot insert two customers with the same name. A better solution is using a specific numeric field (CUSTOMER_ID).
Then, you are defining two table with one-to-one relationship between them; one-to-one relationships are used only in special cases, and I think that this is one of them, because you split the two kind of informations into two distinct tables.
This solution works fine if a customer has only one magnetic card, but when a customer can have more than one magnetic card this design will be wrong. Maybe defining a one-to-many relationship between the two tables is a safier choose for the future.


I agree however I see your forms being very long if you have 50k employees