Jim Starkey wrote: > 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.
Yes. Although I would add that it's not necessarily about number of round trips, but also about intelligent and efficient selectivity in general. Less rows processed on the server in general is typically good. OTOH, I think the opposite point is also true, and is similar to what we did with security already. If you _aren't_ using tons of crazy types, and if you can just stick binary representations of your data in the columns and the indexing will work fine, then the architecture cost for supporting the other stuff should be minimized. > 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++. Hey! Looky here - I (mostly) agree with you. I think that a sandbox-ed VM environment for extensions is potentially fantastic. Folks like Linden Lab and Facebook do this sort of thing (or variations on it) for code that they let J-random-user upload into the system. The UNIX user space could also be argued to be this sort of encapsulted extension on top of the UNIX kernel... but then I think we'd be getting into a very long semantic debate so I'll drop it. However, I would _love_ to get extension ability in a manner like you are referring to here. I also think, however, that the ability to have loadable C or C++ is useful for a different set of things... and some of these do involve that word you said - trust. Taking Apache as a good example. I can "trust" the Apache authors, and I can also "trust" the authors of "mod_perl", or even if I'm crazy, the authors of "mod_auth_mysql". I, right now, have VirtualBox running on my machine which loads a kernel module, and I install DRBD at client sites all the time, which also loads a kernel module. I use mod_perl on my webserver - not even because any of my website is in perl (it isn't) but because mod_perl allows me to embed Perl snippets in the _configuration_ file, which really helps me do hosting for folks. I would never expect the authors of Apache to directly provide embedded perl in the config files - that would actually be a stupid choice. But from an extension module with access to the whole stack, it's brilliant. And it's a choice I can make at installation time. > 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. I'm also not entirely sure who I'm supposed to not-trust in this scenario. The sys admins? > So the choice is basically a) do without extensibility, b) do it right, > c) do it wrong. If these are my only choices, I think I'll pick b... but I reject the implied definitions of "do it right" and "do it wrong here". >> 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. > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
