NYCPHP Meetup

[Tim Lieberman]

On Sep 12, 2009, at 9:09 PM, Matt Juszczak wrote:

>> I used to use the former method almost exclusively.  However, as I  
>> started playing with various frameworks, I've switched to the  
>> latter as those I've worked with kind of expect it.  Probably  
>> because various _call() based magic ends up looking nicer in  
>> userland code.
>>
>> If you have more specific considerations, feel free to get more  
>> specific.
>
> Hi Tim,
>
> Actually, you probably just covered about 99% of what I've read  
> today, which is both a good and a bad thing - first, it's good  
> because I know that information is out dated, but bad because I  
> still have a few questions!  But I'll try to clear my questions up.

[snip]
>
> As you can see, each customer as an account_id.  But each account  
> also has type_id.  I chose to do this like I did above, but why  
> didn't I call the tables:
>
> customer
> customer_account
> customer_account_type
>
> After all, that would have worked the same way, right?  So I never  
> really know where to put the top level.  Is it just up to the  
> person?  My guess is, does it just only matter if the table names  
> aren't self explanatory? For instance, if I just had a table called  
> "type", that isn't really verbose, which is why I put account_ in  
> front of it.

For lookup tables like an "account type", I'd certainly call the table  
"account_type", and not just "type".  Eventually you'll have an "order  
type" to deal with, so ... yeah.

In the larger picture, you want to maintain enough specificity to keep  
things from getting confusing.  This is largely a function of the  
domain.  However, domains tend to grow, so it's better to err slightly  
on the side of verbose specificity.  For example, it's probably not a  
terrible idea to use "customer_account" instead of just "account", in  
case 12 months from now you need two new kinds of ".+_account"s


> Also, as you can see, I only tend to use underscores when I'm  
> referencing a column in another table.  type_id for instance is  
> account_type.id. Which is why I did "firstname" or "companyName" (I  
> did this on purpose to show two possibilities).  Which one is the  
> better one to use? first_name/last_name/company_name or firstName,  
> lastName, companyName? The problem is, if I use first_name, but I'm  
> also using type_id, then some people might think that first_name  
> references a column in the first (or a similarly named) table called  
> "name".

For column names, it's tempting to give a specific meaning to an  
underscore, like you do.

I tend to avoid that, as underscores can be really useful to keep  
things legible.  lowerCamelCase, to me, is just kind of ugly in myslql  
and other rdbmses where identifiers are case-insensitive.

If you really want, I suppose you could use a standard where a double  
underscore indicates some foreign key: account__id REFERENCES account.id