NYCPHP Meetup

[tedd]

At 1:18 AM -0400 8/30/09, lists at nopersonal.info wrote:
>-snip-
>
>In MySQL the exp_date field data type is DATE. I strongly suspect that
>I'm handling my dates in the most verbose & confusing way possible,

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.

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.

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 know for a fact that I didn't properly normalize my tables. IOW, I
>managed to make things work, but it's a big mess.

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.

---

>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.

-----

>Sometimes I sort of feel like Sisyphus. *sigh*

Try Penicillin -- I hear that works.  :-)

Cheers,

tedd


-- 
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com