[Pdx-pm] (OT) SQL style question
kyle at cepaso.com
Thu Jan 13 15:16:13 PST 2005
But why does that have anything to do with column or table names? That
information should all be in your O-R model, not in the DB schema. The
whole point of passing objects into (and receiving them out of) an O-R
model is to *abstract* the workings of the underlying datastore. If
you're finding yourself wondering about this kind of thing, maybe the
O-R abstraction is the problem (and in this case, not abstract enough
it seems), not the underscores or periods or backticks or quotation
marks in the column names...
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.
Central Park Software
On 13/01/2005, at 14:39, David Wheeler wrote:
> On Jan 13, 2005, at 2:26 PM, Kyle Dawkins wrote:
>> Just out of curiosity, why do you need to know this at all? If I
>> were an app developer, I wouldn't want to know -- or have to care --
>> which table it came from. The whole point of views (surely?) is to
>> have the DB do the muscle work of presenting to you, in a format that
>> looks like a unified table, data aggregated from different places.
>> If you require your app layer to know that information, what's the
>> point of doing it in the first place?
> Because the related columns actually represent separate (contained)
> *objects*. So we need a class name as well as the attribute name.
More information about the Pdx-pm-list