Re: MV and SQL
Date: Wed, 18 Jan 2006 11:27:43 +0200
Message-ID: <dql1mk$a33$1_at_domitilla.aioe.org>
"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1137518381.698723.4020_at_z14g2000cwz.googlegroups.com...
> Yes, it is definitely the case that in the languages packaged with MV,
> there is no compile-time type checking. However, with the DBMS itself,
> one might say that there is no checking at all. The type checking will
> be related to the language used with the DBMS. Saying that MV is
> dynamically typed might be like saying that XML files without the dtd
> or xsd have dynamic typing. Did that make sense?
There are several mixed issues here:
- internal representation of data - data - external representation of data
In a RDBMS one should work with data regardless of its various representations.
Any data can be represented as a string over some vocabulary. The "type" just tell one what is the code used. Saying that MV does not have typing might be like saying that in MV if you encoded some data in the database you cannot get it back without providing the decryption code (that is not stored in the same database).
> I have a little working query and result set in the example in my blog
> this week, and will be getting more down the road. While the query
> language is highly productive for someone using it, it requires
> procedural code in virtual fields behind the scenes. You cannot simply
> have your database and the query language only and then get every
> possible query out of the database, although it sometimes appears that
> way to end-users. Someone has to fashion each logical view (logical
> file) with the right vocabulary, sometimes writing procedural code
> (somewhat analogous to stored procedures) as the logic behind an
> attribute (virtual field). Security is also an issue in MV systems,
> with the security managed by the vocabulary files to which individuals
> have access (not a highly scalable approach so users come up with
> alternatives).
> Yes, it is a more user-friendly language in many respects.
> You can only write a query against a single logical view at a time and
> that view looks like a single list of attributes all associated with a
> SINGLE ENTITY. That does not mean that all data need to come from the
> same file/table. But it seemed really dumb to me when I started that I
> could only ask a question of a single entity at a time. It turned out
> that this is one of the things that makes the query language so easy.
> It is easier to shop for data because your catalog of data is so nicely
> presented.
> They know what they can see through a People entity (often the entities
> are plural as the query language reads more like English then), through
> the Orders entity, and through the Accounts entity. Some users will
> write all of their queries against a single entity, always seeing
> things from the perspective and vocabularly of an Orders entity (file),
> for example, pulling in other data by way of that vocabulary.
>
> LIST ORDERS CUSTOMER_NAME ORDER_DATE WITH CUSTOMER_STATE = "MI"
>
> While others will write theirs from the perspective of another entity
>
> LIST CUSTOMERS CUSTOMER_NAME ORDER_DATES WITH CUSTOMER_STATE = "MI"
>
> Notice the slight difference in vocabulary where when you look through
> the vocabulary of the customer entity, you see orders, plural.
The biggest feature of a MV system might be the possibility to define a domain specific language and mascarading imperative code as data. It seems that imperative code and data are tightly coupled which is exactly the opposite of what usually happen in an SQL system.
Can one also define the code for updating those virtual fields in the same way ? Received on Wed Jan 18 2006 - 10:27:43 CET