Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: MV and SQL

Re: MV and SQL

From: <>
Date: 18 Jan 2006 18:26:29 -0800
Message-ID: <>

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.

Mike. Received on Wed Jan 18 2006 - 20:26:29 CST

Original text of this message