Then what about the reports detail and summarized reports of each class, section,

Sorry, I have no idea what you just said there.

Quote:

a view can be created, but students sessions also ends, students get struck off, school leaving, passing out etc...

what you recommend in that case...

I reccomend that if you are trying to build an entire system rather than the single table that your original question alluded to, then you either learn a bit about designing OLTP systems and The forms of normalization or you pay someone to design your database or you do an online search for template databases of the sort that you require. I am not going to sit and guess as to your requirements, suggest solutions only for you to post back with:
"ahh, but what about this piece of information I decided not to include"

i meant, that if only marking the absentees, how can i create the summarized & detailed reports of present / absentees, an individual student's record, whole class / section / level / campus wise reports. etc...

any idea for that ?

for example, there are 30 students in class 6 - A (similarly in 6-b, 6-c, and so on with other classes)

if i only record the the absent students, then after a month the management staff wants to get the summarized reports showing all students totals., and detailed report for each day of all students.

hope you got my point.

pablolee wrote on Thu, 21 May 2009 23:24

Quote:

Then what about the reports detail and summarized reports of each class, section,

Sorry, I have no idea what you just said there.

Quote:

a view can be created, but students sessions also ends, students get struck off, school leaving, passing out etc...

what you recommend in that case...

I reccomend that if you are trying to build an entire system rather than the single table that your original question alluded to, then you either learn a bit about designing OLTP systems and The forms of normalization or you pay someone to design your database or you do an online search for template databases of the sort that you require. I am not going to sit and guess as to your requirements, suggest solutions only for you to post back with:
"ahh, but what about this piece of information I decided not to include"

The first thing that you must do is get as complete a list of requirements as you can. Use that list to create a list of information that you will need to either store, or be able to calculate. Then use that list to create a list of columns that you will need. You can then start to consider your structure at this point.

the detail table is just to select the student, its roll number, campus id, class id, section id, and attendance status (as when the student will be promoted to next class, the history should be maintained)

the user only inputs the absent students, when before saving there is an option that should the system automatically mark other students as present. then in the post forms commit trigger, the system add the record of remaining students as present in the detail table, (how ever the records can be updated next time via querying)

Just a word on de-normalized tables (the 31 column idea). It's acceptable to break 3NR by have repeating fields when the number of those repeating fields is fixed (months of year, days of week, number of holes in a regular game of golf etc are some examples). Number of days in month - well 31 is close enough to be considered.

The good thing about repeating fields is it's easy to ensure that each of the 31 days has a value. It's much harder to find missing records in 3NR when a full up to 31 separate records is required.

Querying over 31 repeating fields becomes more difficult to answer many questions though e.g. list students who missed more than 1/2 of their classes...

As a practical matter, if your input and reporting screens are going to have 31 columns, it'll be easier to code because your presentation format matches your storage structure. This statment will probably draw plenty of valid critisism though...