tedd wrote: > True, you're not handling the date thing correctly, but you're close. > > You need to understand how the date was entered into the database. > > Check out: > > http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#function_date > > and review the DATE and NOW functions. > > Once you find out the format of how the date was recorded, then you can > figure out how to extract and use the date for calculating your > expiration date.
Oooo, good page. Kind of bit scary looking, but good nonetheless. > As for verbosity, I'm all for it if it's in the name of clarity. You > don't need to be cryptic for your code to work. Just the opposite, take > whatever steps you think you need to detail what you are doing. > > I often start with a simple statement telling what I expect the > following code to do, such as: > > // This extracts the full name of the tutor from the database > > and then I write code to do that. Each step is clearly laid out with > documentation. If I have to use extra variables to understand what's > going on, that's not a big deal in my book, but clarity is. Pretty much every line of my code is commented--if it wasn't I'd never remember how to do anything from one day to the next--I only took out the comments because I didn't want to bore you guys with it. I feel better knowing that it's okay to be verbose, so thanks for that. > Take your time, think things out, and organize your code into small > solution for small problems. Understand each step. Eventually, the > bigger problems will reduce into small problems and you'll find you've > finished. And you've finished you will understand what it does. I think that may be where I've often been going wrong--i.e. I try to think about all of it at once, then I get confused and panic. Great advice; thanks. > Normalizing tables is not intuitive, or at least it was not for me. The > simple rule is to not duplicate data in your database. For example, if > you have a Customer table that holds the name and address of someone and > a Purchase table shows what the person purchased, then you do not have > to repeat the name and address field in the Purchase table. Instead, you > use the index of the person from the Customer table to identify them, > such as: > > Customer table > id first_name last_name address > 345 Bev Woohoo 123 Tulip > > Item table > id item_name cost > 1576 Hair Setter 39.95 > > Purchase table > id customer_id item_purchased > 2003 345 1576 > > If you will review the above tables, you will see that by looking at the > Purchase table, you can deduce the customer 345 (you), purchased item > 1576 (Hair Setter) for $38.95. Neat huh? > > Of course, you can add things like inventory to the Item table and date > of purchase to the Purchase table, and zip code to the Customer table, > but this example was simply to show you how these three tables can be > used to provide the data you want without repeating the data anywhere. > Everything is done via indexes. > > --- Good stuff. Lack of normalization has cause me a lot of grief so far. I've been doing some additional reading on it and I'm starting to understand it a little, but every new example helps. >> I'm currently trying to redo everything, but with limited success as >> trying to grope my way through the fog of my inexperience results in >> frequent rounds of tripping & falling face-first into the mud. I >> eventually figure stuff out and inch my way up a little, but it's a >> slow, painful climb. > > If you know some other way, please let me know because that's the way I > learn. > > ----- I wish I knew another way. No, that's a lie--I enjoy learning. The more difficult the challenge, the greater the feeling of accomplishment when you finally get it right. >> Sometimes I sort of feel like Sisyphus. *sigh* > > Try Penicillin -- I hear that works. :-) LOL Bev _______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show_participation.php
