Roland Bouman wrote:
Hi Monty, All,
This brings up what I was chatting about last night, which is pluggable
types. And for that matter, types not being totally tied to storage
mechanism.
[...]
But then if I could define a type that was "Static PPM compressed URL"
that stores into a BYTES, the yippee! We've got something that defines
some behavior and some constraints, and we don't have to have
eleventy-billion different basic types - but people _can_ have types
that make sense for them.
Of course, this means that a pluggable type needs to be able to be done
in a sensible way. Defining the types through SQL a-la the standard is
retarded. SQL is a query language for crying out loud.
I think this is a very interesting thought and I would love to see
this feature. Personally I have never looked in detail into the
standard with regard to user defined types so I cannot comment on how
retarded that is.
What I am wondering about is how you think about defining (or maybe i
should say, overloading) operators for user-defined type. I mean, it
seems to me that specifying values of a certain type (and eventually,
storing them) is one side of the story. THe other is making stuff like
+, =, and function calls work. (and I guess as an extra, indexes on
custom types)
What do you think? Is this something you feel should be part of the
type definition? If not, how will values of custom types interact with
expressions that use them?
I'm on the fence for user defined types for Nimbus. I spent some time
recently discussing their utility and implementation (and, might I add,
giving me the opportunity to miss out on a discussion of materialized
views!). I've comes to think of them as a semantics layer for blobs.
The definition of the type would include, minimally, methods to
serialize and deserialize the content to and from the blob, methods to
export indexable keys, methods for comparisons, accessor methods for
scalar properties for SQL manipulation, and maybe other good and
valuable stuff.
The example given me was the internal representation of an airline
ticket, which also involves the route, the original prices, the change
history, the price, seat numbers, identifiers, etc. A vast quantity of
gook, all of which is necessary for an airline to do almost anything
with regard to a passenger except lose his/her luggage. This could be
normalized, but at great and unnecessary expense. The airlines have a
more or less standard encoding for this gook, which would constitute the
blob. To do SQL operations on it is hopeless in its raw state, hence
the need for user defined types.
This pattern exists through a great deal of the data that databases
regularly handle. Jpegs have all sorts of useful information in them
that a database could use. So do PDFs, open office documents, Word
documents, etc. User defined types given the database system the
opportunity to do intelligent things beyond store and fetch which, after
all, is the rationale for SQL databases over file systems in the first
place.
This does fly in the face of Brian's philosophy that database systems
should be smaller, dumber, and faster. But then, I never bought his
argument in the first place. My philosophy is that any operation that
is less expensive than a round trip between the client and server is a
candidate for inclusion in server. It is fairly clear to me that user
defined types meet this rule and should be give due consideration for
inclusion.
But, maybe Nimbus Version 2.0.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
