Re: MV and SQL




<michael@xxxxxxxxxx> wrote in message
news:1137637589.943828.10850@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> 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.

Are you sure that a column in Pick is equivalent to a column in an SQL table
?
Are you sure you are not confusing physical storage with logical relations ?
If a column is called phones then it is expected to "store" phones not
moneys and phones.

> > - 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.

I only said that an SQL DBMS can do this too with the exception that one
cannot modify the DBMS.

> > - 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.

SQL is not the only language. It can be used with other languages like VB,
JAVA, C#, proprietary/standard stored procedures languages, C, C++, COBOL,
ADA, etc. Some of these can be used to write code running "inside" the
DBMS. Some of these can be used to extend the base types/indices supported
by the DBMS. Some of these can be used to write code running "outside" the
DBMS.
Besides the query language of Pick (search, list, etc.) what other ways do
you have to access the data ?
These access methods are for Pick what SQL + proprietary interfaces are for
an SQL DBMS.

> 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).

I was not saying that Pick cannot do the above. I was saying that one can do
the same things using an SQL DBMS.

> > - 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.

I was saying than one can describe the tables, enter the data and retrieve
it whithout having to write various sorts of code like locking code, IO
code, code for virtual fields.


> > 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.

I was talking about a C compiler not about an SQL DBMS.
Using a C compiler you have total freedom to develop whatever you like. You
don't have to use SQL or an SQL DBMS or even Pick.

> >
> > 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.

What SQL limits one to ?
SQL is only a sublanguage always used together with other general purpose
language.
It's like saying that a Pick system is bad because the Pick query language
is very limited (more limited than SQL in fact).
If one have an SQL DBMS with unlimited field size and a general purpose
language one can develop any database application using only one table with
only one column and only one row. But that doesn't mean he should.


.



Relevant Pages

  • Re: MV and SQL
    ... > - have the liberty to define any field to be a varchar no matter how bad the ... perform enquiries on it using the query language then, again, how the ... talking about what goes on within the DBMS. ... can execute SQL commands or be called from dictionary items used within ...
    (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 ... With an SQL DBMS one can use a language that suport the Variant data type ... You do the same thing when you use DataBasic with the Pick query language ...
    (comp.databases.theory)
  • Re: MV and SQL
    ... >> What an SQL DBMS can't do when one can do anything with it. ... > Are you referring to SQL as a general language? ... No. I'm referring to an SQL DBMS and using SQL + a general-purpose language. ...
    (comp.databases.theory)
  • Re: Is SQL a good language for this problem ?
    ... having a variable number of key/value pairs, where the names of the keys ... The problem I have is that I can't find a way of doing this in SQL that's ... Basically you are asking to re-invent precisely what an SQL DBMS does for ... and dynamically construct your queries using its metadata. ...
    (comp.databases)
  • Re: sql tables
    ... SQL tables". ... All of the "major" SQL DBMS products permit storing more than one identical ... ColumnA ColumnB ... I see this confusion all over the language, ...
    (comp.databases.theory)