Jay Pipes wrote:
Jim Starkey wrote:
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.
Necessary? It isn't. Nothing is necessary. A database can be a simple
store/fetch with no added value. It's faster, of course, is databases
can do selective retrievals, which requires comparisons. And it's
useful if database systems can differentiate between string, numbers,
and dates so it can do useful comparisons. And it's useful if database
systems do joins to eliminate the number of round trips to get required
data. It's also useful for databases to do arithmetic so they can
handle more complicated queries, and so on and so forth.
The point is that all of this complication is useful: It allows the
database system to do, the client to do less, the amount of data
transfered and the number of round trips to go down.
Historically, MySQL tended to eschew strong architectures in favor of
hundreds of special case hacks, which lead to bloat and an
unmaintainable code base. I don't expect anyone to agree with me, but I
believe that a strong architecture that supports encapsulated extension
is a better way to do things. In specific, I think that supporting
loadable C or C++ is a terrible idea. I went there in the 1980's with
Interbase and regretted it. Even if you have decent APIs (and drizzle
doesn't), there is still the security/reliability problem of loading
untrustworthy code. These issues have been dealt with in languages like
Java, but are unsolveable in C and C++.
I think drizzle would be way ahead of the curve if it support a
theoretically defensible way to permit encapsulated extensions of user
semantics than by either supporting hundreds and hundreds of special
case hacks or allowing j-random code to run loose in what would
otherwise be a trusted server.
So the choice is basically a) do without extensibility, b) do it right,
c) do it wrong.
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...)"
Then use a raw file system. Everything else is added value and we're
just arguing about where to draw the line.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
