|
From: Andreas M. W. <amw...@ya...> - 2001-08-07 21:01:40
|
Ciao, To be honest I've been spending a lot of time getting ready to move, so I haven't worked much (if any) on the project. For now I don't think it'll really matter much if you have MySQL installed or not. The dependence on MySQL isn't in the actual database code, that's all vanilla SQL, but in the PHP code is where the dependence is. I wish PHP had a generic database code that would do basic interface to any database backend that it finds....but oh well! > > # > > # Table structure for table 'class_history' > > # > > > > DROP TABLE IF EXISTS class_history; > > CREATE TABLE class_history ( > > student_id varchar(10) default NULL, > > class_id int(7) default NULL, > > grade char(3) default NULL, > > uid int(10) NOT NULL auto_increment, > > PRIMARY KEY (uid), > > What was uid again? uid was a 'junk' value I gave so that there is a unique key in the table for being able to operate on that specific record, with no chance of changing another one. > > # > > # Table structure for table 'class_info' > > # > > > > DROP TABLE IF EXISTS class_info; > > CREATE TABLE class_info ( > > id int(7) NOT NULL default '0', > > number varchar(9) default NULL, > > instructor varchar(60) default NULL, > > time varchar(10) default NULL, > > One thing: "time" is an SQL reserved word; if you're interested > in portability you should call this field something else but if > that's not a big deal to you, then "time" should still be fine. > > > semester varchar(8) default NULL, > > year int(4) default NULL, > > I think "year" is a reserved word too... see above comment. Hrm....quite true, I think they both are...I'll have to fix that (mental note...actually, I'm thinking I'm going to use a tracker so that I have an easier way of remembering it...) Either way, I'll make the change. > Just a thought: since table definitions are potent documentation, > you may want to call fields "explained_absences", "class_id" etc. > instead of "ea", "id" etc. I'll have to think about that...I had shortened it to try to reduce typing and reduce error in typing code. > > grade1 char(3) default NULL, ... > > uid int(10) NOT NULL auto_increment, > > PRIMARY KEY (uid), > > What was uid on this table? Same as above. > I was going to point out that address_id need not be a key, but > you already noticed that so that's good. Did I say it is in the design docs? I'll need to change that if I did. > Isn't it weird how "Mother" starts with "M" and "Father" starts with > "F", but when you see a bunch of "M"'s and "F"'s in a table, you think > male/female, which is the exact opposite of what they mean here? > Weird. Anyway... I've noticed that too... > Playing around with some test queries, I thought that it might be > better if I backed off from what I thought before and called this > field "primary_contact", and make it a char(1) containing either > "Y" or "N". Probably be more meaningful on forms anyway. > What do you think? I'll think about that...get back to you in a couple days. > Also a key of the first six (or so) characters of the last name, > since I think you mentioned that some of the queries will be by > last name. I thought about that, but then I started to think, just how much will be searched by last name... I theory they should have access to a SSN someway to find the student, but I supose that's an option I should provide... I'll get back to you in a few days about those questions I didn't answer...some good points. BTW, I've joined the developer's list also, so if we just hit the list with the mail we'll get anyone/everyone. -- - Andreas Welch ~ amw...@ya... . . KHAW Productions / V \ http://www.khawproductions.com /( )\ "Welcome To The Real World!" ^^_^^ PGP Key: http://www.khawproductions.com/andreas.welch.key _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |