I need a little bit of help here. For my senior project, we've been pushing our sponsor a lot to let us use ASP.NET instead of classic ASP. It is newer technology, much nicer to use than VBscript, and it is one of the hot things right now, so it would look better on a resume since most of us are graduating soon.
The problem? Our sponsor knows nothing about this stuff, so she relies on her graduate student that works there. This guy is an incredible pain. He has already been pushing some things causing an inferior design (two applications in the same database sharing some tables... would be better for 2 separate databases with views). He has a limited knowledge of the technology and doesn't want us to use anything he doesn't know (he can't learn, I guess), and the sponsor takes his word as the bible. I know straight out he is wrong, but she still believes him.
Now back to ASP.NET. Last week he was feeding us this bull about not wanting to use ASP.NET because there are “ASP.NET License” fees. I told him I have never heard of such a thing. .NET is a free download. All you need is IIS, which comes with Windows Server. Can you guys please verify this for me. I am not 100% sure that at the big corporate level there isn't such a thing. When he was telling us this, the sponsor wasn't there. We have a meeting with them on Friday, I plan on bringing it up there, in front of the sponsor, to say it will not cost you and thing and to not jerk us around.
Have been working a lot on the database design for my Senior Project, since our requirements specification are due very soon (and its being very stressful lately).
Noticed a terrible flaw in my database design though. In going through and estimating the growth of the tables and calculating the size, I found that one table would have an annual growth of 32,000 records per year. This is somewhat unavoidable. We estimate 800 users (20 campuses, 20 courses per campus, 2 users per course) and an average of 20 questions on the survey (1 surveys are dynamic, so can't have all the answers in one record, since surveys slightly vary from campus to campus and can always be changed).
The big problem was that in our original design, the size per record was 101 bytes. That comes to about 3mb of space a year, in a table that is always being searched and constantly updated (more surveys filled out and statistical reports run on current and previous data).
Found we could easily reduce the record size to only 16 bytes by using an autogenerated index in the main table it linked to. This other table had a big composite primary key made up of the userid (int), campus name (varchar 50), course code (varchar 10), and semester title (varchar 25). Changed it to an auto increment int id, and back down to a more decent growth size.
Now the question, in most situations, do you use composite keys or auto-generated keys? I had asked this to one of my instructors and he said he only uses auto-generated keys in rows with a lot of inserts/updates and where unique data might be harder to come by (you don't want to use an email address as a userid if you allows users to change their email address, or if data could somehow reoccur). After doing the growth estimates on our tables, it looks like a couple of them could use auto-generated ids.