[eluser]jedd[/eluser]
Now .. I was in the middle of a lengthier response when that one turned up. I'll get back to it
Fuzzy - you should flag this first post in your Helpful Links List - it's a pretty close-to-perfect question (in the sense of what was provided, not the specific problem).
Zebake - you probably want to read up a bit on [url="http://en.wikipedia.org/wiki/Database_normalisation"]database normalisation[/url]. It's a pretty dry subject, but designing your db right (or at least mostly right) at the beginning will save you a world of troubles later on. As you observed, the insight someone gave you above actually answered questions you knew you didn't have yet but soon would.
Whenever you find yourself writing something like
address_alt or
email_2 .. you know you're doing something wrong.
I'd actually blow out the number of tables even further. It sounds like it's making it more complex, but it's actually saving you complexity later. Also there's this natural resistance to multiple tables, where one or two 'should do the trick okay', when you're starting out - as you probably also expect there's a performance hit to be had. Generally there isn't. Databases are designed to do exactly the kind of thing we're talking about here - aggregating and cross-referencing multiple tables
really really fast. If you're in doubt, set up a test bed and run up a million or so rows under each scenario and do some performance testing. Test data is cheap! (And very informative.)
Oh, anyway, yes, to turn that ramble into something specifically related to this problem. I'd have a separate table for email addresses, street addresses, possibly mobile/cell phones (but usually you just get (w), (m), (f), and (h) phone fields and be done with it for a given contact). Given the context I wouldn't bother with a zip_code table .. so no one can accuse me of going overboard.
results .v. result_array - I always use arrays, but I don't come from an OO background so this feels more natural. The facts are that they are usually smaller and consequently faster, and I very rarely have any need for OO features of returned database-row objects.
Oh, one final thing that might bite you later, when you start doing slightly more complex things, is the distinction between $this->data and $data - you're using the latter here, and it'll work just fine, but it tends to break when you rely on things being inserted into $this->data in other locations (typically MY_Controller - when you extend the base controller class). Have a read up on it, anyway, just so you know it's out there .. waiting for you.
