Jim Starkey wrote: > The problem with parsing SQL on the client is that sooner or later you > will get smarter, have new requirements, or probably both. Then you > will need to change the encoding. When that happens either a) you will > invalidate old clients, or b) the server will have to handle legacy > encodings forever. Neither is particularly palatable. If you are > convinced that you will never have a better idea or are willing to stick > with bad ideas if you have a better one, by all means save a few > microseconds with an unnecessarily complex and bloated client.
So, I agree and disagree. :) I agree that the encoding has to be designed to either handle change, or the server has to have a pluggable ability to deal with completely different encodings. The thing we've been chatting about here isn't in necessarily making the client handle the parsing et al, but rather _allowing_ the client to. So that if the code to handle this is modular enough, the client could link it in and so could the server, allowing the client to still send SQL to the server if it wants to. We've been chatting about possibly using the Google Protocol Buffers for this (although granted, that's an implementation detail) but if we did, then some of the ideas are: 1) Client sends SQL to server. Server executes. (No difference to today) 2) Client sends SQL to server. Server returns serialized statement to client. Client sends statement to server several more times. (Client-side stored prepared statements) 3) Same as 2, but client also sticks the statement in memcached for use by other clients 4) Client sends SQL to server. Server saves statement somewhere. (server -side prepared statements) 5) Client parses SQL and sends statement to server. 6) Client never writes SQL at all in the first place, and just constructs a statement object. (backend to ORM systems or the like) (there are a few more obvious permutations of the above...) > The really nice thing about SQL is that it's character based (oops, I > almost said ASCII), so SQL can change without changing the plumbing. > > A small client is a happy client, and a smaller client is an even > happier client. The best way to do thing is to make the client 100% > plumbing and 0% database semantics. Well, yes and no. I think the ability to have a very small client is a wonderful thing. (mmm, REST interface direct to DB) But I also think that sometimes scaling some of these Facebooks and the like requires pushing as much stuff as far towards the edge of the cloud as possible where adding more servers is easy, where even a small extra cost on the hard-to-scale central server is deadly. Of course, the hard-to-scale server part is something where I think you might know someone working on that... :) 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
