Re: POD speed
From: Lee Fesperman (firstsql_at_ix.netcom.com)
Date: 06/11/04
- Next message: Norbert Staiger: "error 245 in Informix JDBC"
- Previous message: lionel pacoud: "bytea SQL ERROR with size"
- In reply to: Chris Smith: "Re: POD speed"
- Next in thread: Chris Smith: "Re: POD speed"
- Reply: Chris Smith: "Re: POD speed"
- Reply: Thomas Ganss: "Re: POD speed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 11 Jun 2004 08:48:53 GMT
Chris Smith wrote:
> Lee Fesperman wrote:
> > You seem to think that using ad-hoc, error-prone techniques is
> > perfectly fine...
>
> Nope. But I do think that there are costs to making a design decision
> that involves an RDBMS versus a more transparent form of persistence.
> It adds complexity to a project by ensuring that you are working with
> two representations of data. Even the best true O/R mappers (by which I
> mean those that map data to existing database schema; those that
> generate schema from the app-specific data model are better described as
> an OO data persistence layer that happens to use a relational database
> as part of the implementation) impose substantial restrictions on your
> use of a programming language, in order to ensure that they understand
> how to map the result to the database.
Nope? Can I get something more to the point? Do you believe that such alternatives (such
as, simple object persistence systems) are not ad-hoc and error-prone? I know of no
theoretical basis for these techniques. Can you enlighten me on this issue?
I do see a number of difficulties with using O/R mappers. I expect only small
improvements in the future. A good O/R mapping solution is always going to require
significant participation by a 'developer' with problem domain knowledge.
The double representations of data is natural. The application view is concerned with
the functionality of the individual application. An application written in an OO
language would prefer data expressed as objects oriented to operations performed by the
application. The database view is concerned with persistence, use by different
applications, integrity and other database considerations. These are fundamentally
different concerns.
Would you see it as reasonable that two applications accessing the same database tables
might use a differnt object/relational mapping -- that is, different objects? To do
otherwise would be violating encapsulation.
> (And I don't know if you reject O/R mapping entirely; I know that a lot
> of the more extreme "relation data is the world" crowd do. Personally,
> I find them to be rather useful tools; though I do think they are
> inappropriate for a substantial class of applications, specifically in
> data mining.)
Object/Relational mapping is OK. It elucidates the dichotomy between application
orientation and database orientation. Application considerations shouldn't influence the
database structure design. O/R mapping could help prevent that.
> > Let me try (once again) to bring you back on topic. The original
> > discussion was about using POD vs. a SQL DBMS, today. My statement
> > was made in that context -- it is my 'opinion' that an object
> > persistence utility (like POD) should only be used for "the
> > simplest, single application, that will never change." Otherwise, a
> > RDBMS, realistically a SQL-DBMS (excluding weak systems like MySQL +
> > HSQL,) should be used. POD and such are ad-hoc and error-prone.
>
> And I disagree with pieces of this, if you want to talk in that
> direction. Specifically, I would say that:
>
> 1. The difference needs to focus on the scope and nature of the data,
> not the simplicity of the application. There is a large amount of data
> that is either so application-private that it makes no sense to expose
> it via a universal relational model because no one else will want it
> (for example, a parameterized strategy for a particular kind of problem-
> solving activity that the software performs). There is a second class
> of data that's sufficiently inappropriate for the relational model that
> it's best to steer clear (for example, I'd shudder to imagine
> representing an arbitrary math formula in relational tables and trying
> to perform useful translations on it).
Certainly, the scope and nature of the data should be a focus point. However, you give 2
specialized examples without sufficient description to understand them. I can't tell
from that whether an RDBMS is appropriate. It might be, but I don't see any reason to
delve into them just to judge the validity of your assertions.
> 2. I disagree with the "that will never change". This isn't just a
> relational DB thing; I generally disagree with the idea of designing for
> what a business software system will be like years from now. Experience
> has shown that in business software development, we rarely have better
> than a vague idea of what the application will look like six months from
> now. If the application moves in a direction where a relational
> database is helpful, it's easy enough to migrate the data over,
> especially if it's local enough that it made sense to use a transparent
> object persistence layer for storage.
What you're talking about might be called "design for the future". I am talking about
designing for the future but not in the sense of predicting changes, including hooks and
'extraneous' code, etc.. I was referring to designing a normalized database structure,
with no extraneous tables/columns.
Because Normalization and RM are concerned with the meaning of data in modeling the real
world, a properly designed database is much more amenable to change than any other data
model. RM eases migration to new structures with powerful abstractions like views,
allowing existing applications to run without change. Views have a number of other vital
uses (the lack of them is one reason I call MySQL a weak system.)
> (Incidentally, this is different in system-level software such as
> compilers or the databases themselves; the difference is that you have a
> more solid picture of what the final system should look like and the
> problem that it solves is more exactly described. These are
> characteristics that will never be true of most business software simply
> because it's fundamentally rooted in human factors.)
I have been considering system software as different from applications, though I have
written compilers/interpreters that used a relational database.
> > I'm afraid I don't know what Maple is, but the other applications you
> > listed are horizontal, even utilities rather than applications. I
> > believe the 'great majority' of applications are vertical, which tends
> > to vitiate your point.
>
> (Incidentally, Maple is a computer algebra package.)
>
> I don't see that. I have no numbers, but I tend to believe that back-
> end enterprise software systems comprise by no means the average
> software system in use. In a typical day, I use at least half a dozen
> to a dozen end-user software applications, and I interact with about
> four enterprise-level applications. When you consider that the majority
> of the world is not employed in IT or software engineering, I'd tend to
> think that the numbers differ even further for others.
We seem to be counting different things. You are counting users, and I am counting
different programs (developers). That's why I considered horizontal software unimportant
-- there are only a few main-stream word processors.
> Regardless, it seems worthwhile to restrict discussion to enterprise
> business software, since that's generally the target audience for this
> newsgroup.
I was considering a different range of applications, those using or contemplating using
a database, from POD to Oracle. Limiting the discussion to enterprise business
applications would virtually eliminate POD from consideration. I think the former better
fits this group, anyway. OTOH, I believe discussions of whether a database should be
used or not are also germane to the group (there is no
comp.lang.java.databases.advocacy.)
> > Unlike you, I believe most software out there is mediocre at best.
> > I'm embarrassed by my craft; I'm sure that they could do better.
>
> That would be a difference between us. Again, I would tend to link it
> to our differing perspectives on database as well. I tend to think that
> software development is doing fairly well. Sure there are horrendous
> failures, but there are plenty of successses as well. Software
> development is fundamentally about human communication... interpreting
> what people want and translating it into a precise description in
> software. Given that, we're never going to get it down to the same
> level of predictable processes and results as, say, welding or house
> framing; but we are doing fairly well.
Not surprisingly, I'm more concerned with improving current tools, rather than improving
people skills. Certainly training will help with the latter.
With main-stream languages, programs are complex, fragile and error-prone. One of the
big reasons is that they are basically procedural and use variables.
As to turning software development into a craft or engineering discipline, I don't see
that as a reachable goal. Programming is too dynamic. I've always felt that the primary
reason for developing a program is because one doesn't already exist.
-- Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com) ============================================================== * The Ultimate DBMS is here! * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
- Next message: Norbert Staiger: "error 245 in Informix JDBC"
- Previous message: lionel pacoud: "bytea SQL ERROR with size"
- In reply to: Chris Smith: "Re: POD speed"
- Next in thread: Chris Smith: "Re: POD speed"
- Reply: Chris Smith: "Re: POD speed"
- Reply: Thomas Ganss: "Re: POD speed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
