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.
Why, oh why, is this stuff necessarily done in the database. It is vastly easier to scale this kind of thing without tying the presentational and business logic into the database itself. > 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. Huh? So, what more than "store and fetch" do you want the database to do? Pull a foreground to transparent gradient over all JPEGs in a table? Why on Earth should the database do these things? > This does fly in the face of Brian's philosophy that database systems > should be smaller, dumber, and faster. Yep, sure does! > 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. Considering the round trip is just about the *least expensive* part of working with Drizzle, I fail to see your argument here. My philosophy is: "Have the database server be as quick and efficient at fetching and storing data as it can. Let your application and web/middle tier worry about business logic and presentation (since it's infinitely easier to scale that tier versus the DB tier...)" > 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
