[Pdx-pm] (OT) SQL style question

[Kyle Dawkins]

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.

Cheers

Kyle
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.
>
> Regards,
>
> David