Jim Starkey wrote: > 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.
Agree. > 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. Yes, indeed. > 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. Not necessarily... If we move parsing out to the client, then we could implement pluggable types as a client-side addition, leaving the database server lean and mean, but still giving compile-time errors and data validation hooks. And, if by "to the client" we mean in the client library which the server also has, then you could implement the same UDTs as plugins to the client/parser that's sitting on the server if you don't buy in to the idea of client-side-parsing being a good idea. (for validation, at least) For introspection of that data, such as searching on sub-parts (like, tickets with destination city of XXX) then we get in to the age-old question of should you store it as structured, semi-structured or unstructured. I'm of the opinion that if you _do_ need to examine the inner workings of that blob, you'd be better off decomposing it on the client side and putting it in a table. (that's what ORMs are for, after all) Of course, I have been wrong before... Monty _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
