NYCPHP Meetup

[lists at nopersonal.info]

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