On 9/8/07, <b class="gmail_sendername">Johan Venter</b> <<a href="mailto:mythtv@vulturest.com">mythtv@vulturest.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jay R. Ashworth wrote:<br>> On Fri, Sep 07, 2007 at 03:24:39PM +0100, Mike Perkins wrote:<br>>> Is it not possible, within scheduler.cpp, to break down the BUSQ in<br>>> such a way that it is more comprehensible by the devs and easier for
<br>>> MySQL to deal with? I have done some refactoring of similar beasts in<br>>> the past (~5 years) and know it can make a hell of a difference to<br>>> maintainability if nothing else.<br>>><br>
>> Just saw the prettyprinted BUSQ. OMFG. (picks jaw off floor)<br>><br>> Yeah, I know, right? :-) I didn't know you *could* put CASEs in<br>> querys; is that a MySQL thing?<br><br>Nope, can do it in most compliant databases, SQL Server and Postgres
<br>included.<br><br>I don't know what all the fuss is about, I've written and maintained<br>queries *much* larger than that before - and I'm not exaggerating nor<br>trying to boast.<br><br>I used to work under a developer who decided it would be a grand idea to
<br>have *all* of the business logic for the application we were working on<br>enforced in the SQL queries/stored procedures. I have debugged queries<br>that span *pages* :)</blockquote><div><br><br>The difference there (I'd hope) is that it was with a real database, most likely using stored proceedures and calling on materialized views.
<br></div><br></div>