NYCPHP Meetup

[lists at nopersonal.info]

Kristina D. H. Anderson wrote:
>>> But in the case of a form, wouldn't you be validating the input before
>>> trying to insert the record? Sorry if I seem dense--I must be
>>> misunderstanding something.
> 
> No, you are exactly right, and you'll want to use a combination of 
> client-side (form) validation and good database design, and make 
> decisions based on the individual application.   But, you also need to 
> be aware of other people's database design choices, and code around 
> them.  It's good to know that a blank string is not null when you need 
> to populate a field that is supposed to be NOT NULL but actually has no 
> value to be inserted...and that sounds insane, but I've seen stuff like 
> this over the years, and sometimes it cannot be changed but only dealt 
> with. :)

Ah, okay, I see your point now.

> Also sometimes you're not dealing with forms, let's say you have a web 
> service that's sending you XML which gets processed and goes right into 
> the database without your ever seeing it in the production environment 
> (and this is getting more and more common these days, and there is just 
> nobody sitting around reading a generated log of every response that 
> comes in to check them, like I suggested you do in a test 
> environment...that defeats the purpose of automatically inserting the 
> data!), so the best way you're able to generate an error if fields are 
> missing is if the query doesn't execute...this can happen, say, if the 
> people sending you the data change something and don't bother to notify 
> you...if your fields in the database will accept NULL inputs, you could 
> look a week later and see missing data...there are a lot of different 
> cases and all the solutions are different.

That makes perfect sense in the situation you describe.

*wonders if this programming stuff is ever going to get easier*

Bev ;)