I agree with John (well, I usually do, it's a sensible thing to do!); this
sounds like a Really Really Bad Idea. Tables should be carefully designed to
be properly normalized; throwing them open to arbitrary addition of new fields
would very quickly give an unwieldy, unnormalized design.
What real-life problem are you trying to solve by doing this???
I have several teams which meet different times throughout the year. They
are required to track the attendance of each team member for each meeting
scheduled. There is no set day/time the meetings are scheduled and I was
trying to devise a simple form for each team leader to keep track of their
teams attendance without having to enter the dates multiple times and then
select each member each time for every date. My thought was if the team
leader was prompted for a date, this could become a new column and then they
could click which team members was present for that date (using Yes/No).
This may not be the best design but I couldn't come up with anything else
that worked.
You need three tables: one that has one row for each member (call it
Members), one that has one row for each meeting (call it Meetings), and one
that resolves the many-to-many relationship between those two tables (call
it MeetingsMembers)
Every time there's a meeting, you'd add a row to the Meetings table and then
insert rows into MeetingsMembers for each member who attend the meeting.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.