Re: MV and SQL


x wrote:

> With SQL DBMSs one :
> - have the liberty to define any field to be a varchar no matter how bad the
> design is

Well... with Pick you don't have to define it at all - as a varchar or
as anything else. You just start using it. Saying
"thisfield=thatfield+theotherfield" requires that both thatfield and
theotherfield be assigned a value prior to this code being executed
though - or you get a runtime warning and thatfield and/or
theotherfield are treated as being equal to zero. You can use it as a
"varchar" if you want - and/or as a boolean - and/or as a numeric...
anything. You can perform string operations on it, add it to another
field, then put it through code that says "if
thisfield+thatfield[startlen,forlen]-theotherfield then...". When you
perform enquiries on it using the query language then, again, how the
field is treated depends on its use - or the dictionary definition.
Total freedom. Of course this can be abused - and it often is. People
often experience difficulties when trying to extract data from Pick to
move to an SQL-relational DB because a single field, or column if you
prefer, can have a mixture of data types. As with anything else in life
though, you have to learn how to behave properly if you want to get
along outside of a rigid, disciplined, confined institution.

> - have the liberty to define stored procedures for implementing a domain
> specific language

I guess you could say that everything in Pick is a kind of stored
procedure. Hell - what's an unstored one? Bear in mind here that we're
talking about what goes on within the DBMS. As I said in the post you
responded to, a Pick DBMS application covers any or all of the layers
from client user interface down to file IO. As such, a Pick procedure
can execute SQL commands or be called from dictionary items used within
an SQL command. It can also be called from a VB application to retrieve
data. It can also be used to fire off an executable or generate and
execute script to perform a function on a server/client/browser... I'm
struggling here... Ask me a specific question about what it can't be.

> - have the liberty to choose the programming language and reporting tools
> used to access the database

Ummm.. OK. Here's where I show my ignorance. I thought the only way to
get data into or out of a SQL DBMS is/was through SQL. I thought that
was the only way to access the database. If I'm wrong about that then
please feel free to educate me a little - and have a go at me too while
you're at it if you like.

Of course people use all kinds of programming languages and reporting
tools on top of Pick. I, personally, prefer the browser-web languages
but am also using VB - and a lot of people combine aspects of those two
by using ActiveX components. There are also a lot of Pickies out there
who prefer to use Java on top of Pick. There are also a lot of people
that use various reporting tools written in various languages, some of
them not just sitting on top of Pick, but actually written in Pick -
MITS and Datastage for example - which are often used as the sole Pick
application in an otherwise SQL DBMS environment (because they're
judged by their users to be better tools than those based on SQL).

> - have the liberty to use the DBMS out of the box without any other tools

If you ever get a DBMS out of the box that can't be used without any
other tools I suggest you send it straight back where it came from and
tell everyone about it.

>
> Using a C compiler one even have the liberty to define its own specialized
> DBMS for an application domain.

Again - I plead ignorance. Sorry. I thought you had to use SQL with an
SQL DBMS.

>
> So what is the advantage of MV systems ?

Over SQL-relational? Well - because you can use SQL - if you want - or
you can go way beyond what SQL limits you to. I'll be keeping an eye on
Dawn's blog over the next year or so. I believe it'll go quite a long
way towards answering this question - much further than I can at the
moment.

Cheers,
Mike.

.

Relevant Pages

  • 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)
  • Re: MV and SQL
    ... >> - have the liberty to define any field to be a varchar no matter how bad ... > 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 ... I only said that an SQL DBMS can do this too with the exception that one ...
    (comp.databases.theory)