By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,620 Members | 1,303 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,620 IT Pros & Developers. It's quick & easy.

keep track of Consecutive numbered cards

P: n/a
RR
We have cards that are numbered consecutively. These cards are given out to
different people in different sized batches. One group might get 5, the
next group might get 20.

What is a good way to set up to keep track of which numbered cards are given
out, and to who?

Thanks
Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
If you wanted to keep track of them by using tables and relationships,
then maybe use something like this:

Tables:
Groups
ID - autonumber (Primary key)
Name - text

Cards
ID - autonumber (Primary key)
CardNumber - double

Hands
ID - autonumber (Primary key)
fkGroupID - long integer, indexed dups ok (Foreign key)
fkCardID - long integer, indexed dups ok (Foreign key)
fkSessionID - long integer, indexed dups ok (Foreign key)

Sessions
ID - autonumber (Primary key)
Name - text

Enter all the groups, then enter all the cards. To start, create a
session (I guess I could have called this table Games), and then
distribute the cards to the groups using the Hands table. This
structure will allow you to review Session history, add new groups and
cards without affecting the past, and have different size hands for
different groups (one with 5 and the other with 20, eg).

The downside of this structure is that the Hands table is a big many to
many link table between the other tables. This adds complexity. Also,
this structure doesn't by itself provide the "consecutive numbering"
constraint you mention, or any concept of a required number of cards
per session.

HTH,
Johnny

Nov 13 '05 #2

P: n/a
RR
Thanks for the response.
I am may not have explained the "cards" the way i should have.
The "cards" are actually an ID card. An organization will be sent maybe 5
or 20 to had out to members. I then need a way to keep track of which card
numbers go to which clinics.

Everything I've come up with so far is kind of cumbersom for the user. I
cant help but think there is a better method to set this up.
"Johnny Meredith" <jm*******@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
If you wanted to keep track of them by using tables and relationships,
then maybe use something like this:

Tables:
Groups
ID - autonumber (Primary key)
Name - text

Cards
ID - autonumber (Primary key)
CardNumber - double

Hands
ID - autonumber (Primary key)
fkGroupID - long integer, indexed dups ok (Foreign key)
fkCardID - long integer, indexed dups ok (Foreign key)
fkSessionID - long integer, indexed dups ok (Foreign key)

Sessions
ID - autonumber (Primary key)
Name - text

Enter all the groups, then enter all the cards. To start, create a
session (I guess I could have called this table Games), and then
distribute the cards to the groups using the Hands table. This
structure will allow you to review Session history, add new groups and
cards without affecting the past, and have different size hands for
different groups (one with 5 and the other with 20, eg).

The downside of this structure is that the Hands table is a big many to
many link table between the other tables. This adds complexity. Also,
this structure doesn't by itself provide the "consecutive numbering"
constraint you mention, or any concept of a required number of cards
per session.

HTH,
Johnny

Nov 13 '05 #3

P: n/a
Have you tried a simple one-to-many relationship between Organizations
and Cards:

Organizations
ID
<<Other Fields>>

Cards
ID
fkOrganizationID
<<Other Fields>>

If you've tried that, can you more clearly describe the cumbersome
aspect of it and I'll try to help you resolve this.

If you reissue cards (the organizations give the card back after a
time, and you reuse them), then a many-to-many linking table between
the two may be in order.

Johnny

Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.