Re: [SQLObject] Join tables

[Andy T. <an...@ha...>]

John Baker wrote:

> On Tue, Nov 11, 2003 at 10:04:56AM +0000, Andy Todd wrote:
> 
>>John Baker wrote:
>><rant>
>>I'm not. I'm writing an application which stores its data in a 
>>relational database but which is written in an object oriented style. If 
>>I wanted an object persistence mechanism I'd use something like ZODB or 
>>PyPerSyst.
>>
>>This is something that irks me when working with colleagues who have 
>>limited exposure to technologies other than, for instance, Java. They 
>>are always in conflict with their DBAs (who do still exist btw) 
>>justifying data models where one side is simply using the db as a 
>>persistence mechanism and the other is trying to use the database 
>>'properly'.
>>
>>In general, the right solution is somewhere in the middle. Some of the 
>>more esoteric object associations don't map nicely to databases and code 
>>has to be written in your application to accomodate them. Likewise you 
>>can't always have a third normal form relational model in your database, 
>>sometimes you have to live with a little duplication or non-optimal 
>>storage structures to make the application easier to code. Its all about 
>>compromise
>></rant>
>>
>>Sorry about that, but *I* feel better now.
> 
> 
> That's ok :-)
> 
> DBAs are a dieing breed. After all, who needs a DBA for MySQL or
> Postgres? Alright, so you may be using Oracle, and I pity you :)

Well I still get called one occasionally, but in reality I'm what Scott 
Ambler calls a 'generalising specialist' 
(http://www.agiledata.org/essays/becomingAgile.html). Never mind Oracle 
(all hail Larry), have you tried using DB2? Oracle is great compared to 
that lumbering dinosaur. Regardless, though, you still need to apply 
rigour and method to your use of a database be it MySQL, Oracle, DB2 or 
even SQLite. You may want to call them DBA tasks, I call them 
development activities.

> 
> If SQLObject is to be aimed at a very limited set of solutions, that don't
> lend themselves towards proper OO programming, then perhaps clearly
> stating this on the website would be a step forward. But at this point in
> time, without superset mapping, you cannot model anything more than
> trivial relationships. This makes it rather unhelpful, which is a shame
> because it's actually quite easy to use.

Very limited? Virtually every system I come across these days, both 
professionally and in my own time, has the application code written in 
an OO language and the data stored in a relational database. I don't 
believe that this is entirely because everyone has these Oracle (or 
Sybase or MySQL) licenses lying about and says "Oh, I know, lets use 
this for storing our objects". Its because the relational database 
supplies benefits over and above storing your objects in flat files. 
Otherwise everyone would be using shelve, right?

> 
> Databases are there to store data. They should do no more. I do not
> subscribe to the Oracle approach of, "Let's throw lots of crap into a
> product [nat/firewall/multiple redo files]" in a desperate attempt to
> provide a reason for an upgrade. I've got a bunch of databases, some of
> which have tables that are a mere 500megs, mapped using superset
> mappings. I see no performance issues, although I am using MySQL :)

And I come to the situation from the other side, if you are *just* using 
a databsae to store data then why not just get a decent journalled file 
system on a RAID disk system and use flat files. That way you aren't 
constrained by Mr Codd's nasty rules.

> 
> To the developer, how the data is stored is totally irrelevant. But when
> your developer can't actually model relationships because the system of
> persistence is restrictive, then we have a problem. I've already provided
> two or three examples that clearly demonstrates that SQLObject can't do
> what I want it to do, and I'm hardly trying :-)

Correct. But the developer isn't the only actor in this drama. What 
about extracting data from an operational system to a data warehouse? Or 
writing summary reports on working data sets? Or replication? Or 
point-in-time recovery? Or, shock horror - non OO access to your data?

> 
> It's not my project, and superset mappings would be tricky to
> implement. But as it is, assuming you can't have this type of mapping, the
> foundations of the project are extremely limited.
> 
> And as we all, as good OO developers know, if you build on poor
> foundations, you regret it later in life.

And I return to my earlier point. If you want pure OO don't use a database.

> 
> 
> John

I'm not trying to start an argument here, its plain from our posts that 
we have slightly different points of view. I for one am just happy to 
agree to disagree. Its of benefit to the community (at large and the 
users of SQLObject) to have people with as broad a variety of 
backgrounds (and technical inclinations) as possible.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/