[Pdx-pm] (OT) SQL style question
kyle at cepaso.com
Thu Jan 13 16:01:36 PST 2005
> It's the O-R abstraction that we're creating. We want to take
> advantage of the features of each database to the fullest extent, so
> we're using views to represent compound objects. In sort, we're using
> the database as the O-R layer itself. But there need to be some
> conventions when naming things.
Well, here's where I am still not quite getting you... if you are
creating an abstraction, then store the meta-information in your O-R
model, not in the DB column names... if your abstraction needs to know
that columns A, B and C come from table X and columns D and E come from
table Y, then why wouldn't you store that in your model? I don't quite
understand why you need to derive that information from the DB
schema... especially since you want to support different DBs, which
will almost certainly have different naming conventions. You should
move it up into a mapping system, and perform all reads through that
>> But... there are always good reasons to have a thin abstraction
>> layer, and since I don't know all the details, it's definitely not my
>> place to make any more statements about what you should or shouldn't
>> do. How do you model classes? And relationships? And how do you
>> fetch and save objects? Maybe there's a way to get in there at the
>> right point and map the columns in question to the objects in
>> question without your app-level code ever needing to know about it.
> The app-level code won't need to know, but the abstraction layer will,
> and that's what we're working on.
Good good... definitely the right idea. But if you haven't already
started a higher-level model of your underlying DB schema, now is the
time. It will save you tons of grief and prevent you needing to answer
the question you posed to this list because the whole issue becomes
moot; all column names become irrelevant (which doesn't mean you
shouldn't name them consistently, just that the format you use is not
relevant to your code).
Cheers 2 all!
Central Park Software
More information about the Pdx-pm-list