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
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show_participation.php
