Re: Is SQL a good language for this problem ?

"Richard Robinson" <richardR@xxxxxxxxxxx> wrote in message
news:468b86d8$0$643$bed64819@xxxxxxxxxxxxxxxxxxxx

There's a lot of reading behind that phrase (which was new to me) -
thanks.

No problem. As you read it, keep in mind that there are tremendous problems
with it, to the point where I would question why anyone willing to use it is
even using an SQL DBMS at all since they would be getting no value and lot
of problems from doing so.

Basically you are asking to re-invent precisely what an SQL DBMS does for
you for free.

That was my thought, if I follow you right - there must be good ways of
doing this. I "just" need to figure out how to set things up to ask the
DBMS
properly ...

Yep, that's all there is to it. It's not hard, in fact it is probably
simpler than most kinds of programming, but it is unfamiliar. It is easy to
get spooked and think it is unintuitive, but it is only lack of familiarity.
The principles are so simple as to be almost trivial, so stick with it for a
while.

Find out what metadata (system catalogs) your particular
SQL
DBMS provides, and dynamically construct your queries using its metadata.

I'm sorry, I think I don't know enough to follow you here, would you mind
expanding a little ? Do you mean things like finding out the names of
tables, their columns, info about them, that kind of thing ?

That is just what I mean. Unfortunately the catalogs--which are absolutely
fundamental to a relational DBMS--are probably the least standardized
feature of all the SQL products out there. There are some official
standards but I don't think any product pays any attention at all. Since
you are extremely unlikely to be using a DBMS that I'm familiar with, I
can't offer any detailed help.

The general approach that I might take is to have my application discover as
early as possible which tables it needs to query, and also the kind of
queries it will need to execute. I would then use the catalogs to construct
the SQL to do the required queries and cache that SQL in my application so
that I don't need to consult the catalogs while I am trying to respond to
real-time user requests. Just how this will work will depend on your
application programming language too. It is easy with Java and its like,
and rather harder (but eminently possible) with Cobol and its like.

Roy


.

Relevant Pages

  • Re: Is SQL a good language for this problem ?
    ... DBMS properly ... ... SQL DBMS provides, and dynamically construct your queries ... I would then use the catalogs to ...
    (comp.databases)
  • Re: MV and SQL
    ... >> perform enquiries on it using the query language then, again, how the ... > Are you sure that a column in Pick is equivalent to a column in an SQL table ... If you had some bizarre need to do this in a Pick DBMS though, ... > Besides the query language of Pick what other ways do ...
    (comp.databases.theory)
  • Re: MV and SQL
    ... >> perform enquiries on it using the query language then, again, how the ... > Are you sure that a column in Pick is equivalent to a column in an SQL table ... If you had some bizarre need to do this in a Pick DBMS though, ... > Besides the query language of Pick what other ways do ...
    (comp.databases.theory)
  • Re: MV and SQL
    ... >> perform enquiries on it using the query language then, again, how the ... > Are you sure that a column in Pick is equivalent to a column in an SQL table ... If you had some bizarre need to do this in a Pick DBMS though, ... > Besides the query language of Pick what other ways do ...
    (comp.databases.theory)
  • Re: MV and SQL
    ... >>> Are you sure that a column in Pick is equivalent to a column in an SQL ... > You can also change the type from varchar to array if your SQL DBMS support ... > for variables that store the data retrieved from the database. ... >>> SQL is not the only language. ...
    (comp.databases.theory)