Re: mySQL Problem


"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
news:I8idnbCucsiO867anZ2dnUVZ_ournZ2d@xxxxxxxxxxxxxx
Steve wrote:
"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
too much space? is there a premium on space in your editor, jerry?
would you like me to post a query i have for running financial
statistics here? i would be more than willing to un-format it so just a
single line in order to save 'virtual' space on the 'virtual' page if
you'd like. :)

Don't be an *** again, Steve. My editor isn't limited, but my
screen size is, and that wastes a lot of it.

again? when was i being an *** at all, jerry? i was sarcastically
making a point. one of which is that your screen realestate is far less
expensive than spending the time it takes to debug non-functioning
queries...especially when the query is more complex that what it seems
you've written in the course of your experience. you'd probably start by
*formatting* said query so you could break it down and isolate the
problem. after all of that's done, you probably would spend a fraction of
time fixing the actual problem. if it is formatted to begin with, you are
less likely to introduce problems, more able to expand a query, and very
quickly able to fix whatever else may ail it.


First of all, it didn't come through as sarcastic. If that is how it was
meant, then I apologize.

that's fine.

But this is simple compared to many of the queries I've written in the
past. Try recursive queries in DB2 or Oracle, for instance. Some of them
get very long and very complicated. But I doubt you are even aware of
what a recursive query is.

here we go again, jerry! can you cut down on the overassumptive insults? i'd
stack my 25 years of programming experience against yours any day of the
week. yes, i know what recursion is an any context - even this one where you
continually fall back into the same pattern of insult after insult. most
recursive functions have a drop-out condition so it's not an endless loop.
what's yours?!

And I didn't say don't format - you're putting words in my mouth. I said
your method of formatting is lousy.

well, first you said you didn't care for mine. then you said mine was
stupid. now it's just lousy...all the while missing the point that
FORMATTING is what was being discussed, not MY FORMATTING STYLE. i couldn't
care less about your thoughts on my style...just as you probably mirror in
my reflections on yours, or anyone else's for that matter.

if you stick to the point (formatting) then i'll be far less likely to
assume my 'method' you originally stated disagreement with means 'formatting
in general' instead of 'steve's particular formatting style'. and were that
the case, i'd have said 'i don't care how you feel about it, jerry'. as it
is, you went on a tangent while the rest of us were still talking about
*formatting* - regarless of styles.

if it's that big of a deal, buy an editor with code folding.

again, am i an *** simply because i have been calmly disagreeing with
you?


It's the way you disagreed.

he, he, he. calmly? come one jerry! you've seen enough of my posts to know
when i'm being an ass or tryin to be one. i think something just went wrong
for you today and your sensitive about something wholly unrelated.

as far as being 'correct by virtually any programmer i [you]
know'...that may be as 'virtual' as the space such a query takes up. as
for what is reported, documented, and written about code formatting -
inclusive of sql - i think you're outnumbered.

Yep, programmers with any sense don't do it that way. The do it similar
to:

SELECT a,b,c
FROM x
WHERE y='z';

Or something similar. And in the almost 25 years I've been doing SQL, I
can probably count on two hands the number of experienced programmers
who write SQL as you did. And hundreds who do it the way I learned.

you know what? me too. however, those handful are the ones from whom i
learned the most. they showed me that consistency, simplicity, and
manageability are the keys to not only good code, but a successful
career.


Sure. And what do you do when you have a recursive query with 50
different parameters from 5 joined tables with a half dozen conditions
(not including the joins)? I've had queries run upwards of 2K characters.

what? jerry, the larger and more complex a query, the MORE you need to
format it - indenting, aligning, etc.. i'm not sure i follow where you're
wanting to take this.

Let's see you format THOSE queries the way you espouse and get them on in
a single window in something larger than 1 point font.

you're putting the criteria on it, not me. i couldn't care less if it fit in
a single window or if it required multiple caches to cleanly scroll through
the whole thing.

are you telling me that it is best to leave queries unformatted, especially
the more complex in nature they become? either you're digging your own grave
here, or, you're still stuck on my particular style of code formatting. if
the latter, i could give a flying ***. if the latter, there's no need to
continue the conversation, mainly because you have yet to address my one and
only point - format your fucking sql statements. and just for you jerry,
since you still can't catch on...i don't care how anyone stylistically
formats their sql in particular. to each their own on that issue. now let's
move on.

also, in addition to being an *** for disagreeing with you, jerry,
i'm now a programmer without any sense...and for simply the same reason?!
rof.

i'm chuckling even more now though. don't you notice a difference between
the example you gave:

select a, b, c
from x
where y='z'

and the real formatting issue being discussed here...in the genre of:

select a, b, c from x where y='z'


No, it's the difference between

select a, b, c
from x
where y='z'

and

select
a,
b,
c
from
d
where
y='z'

Now - which one is more readable?

in my opinion:

SELECT a ,
b ,
c
FROM d
WHERE y = 'z'

is most readable and manageable...esp. when i want to add new fields to the
query. i go to the select, hit enter, drop the new field in. if it's all
listed, i'm just adding to a pool. ever have a problem of selecting the same
field twice in the same query? i never have. i can clearly see what fields
i'm working with. notice that i even align my commas and keep them
measurably out of the way of the field list so as not to disturb my view?
and yes, i even align my equations so i get a list of things and how each
relates to some other thing (i.e. y = 'z', etc.).

again though, this is your tangent...not mine. as far as your stylistic
practices or mine, i don't care. formatting v. not formatting. keep
repeating that to yourself jerry. enough times so that it will eventually
sink in that that was my point. then you'll quit arguing over non-sense.

hmmmm...the former being formatted in some way, the latter, not at all.
and i'm senseless?

let's take that example though a bit further and say we're dealing with
php code. if a function has parameters a, b, and c. you probably write it
and call it thusly:

function foo($a, $b, $c)
{
return true;
}


No, I don't. I write it as

function foo($a, $b, $c) {
return true;
}

i bet though, that when your parameter names are very long and numerous,
you either single line them or column-ize them, like this:

function foo(
$a ,
$b ,
$c ,
...
)
{
return true;
}


Nope. If it all fits in one line on my screen, I put it on one line.

about to bust a gut...gotta hold it in...

Otherwise I split it into 2 lines, with the second line indented, such as:

WELL HOLY *** !!! so you COLUMN-IZE !!! did i not mention that? again, if
screen realestate is your only concern here, then why bother to write php in
any other fashion. it parses the same as sql - spaces stripped and so on?
just one line the whole thing. oh yeah, you DO format...you just don't care
for how I format. not my point or a concern of mine, jerry. argue that till
you're blue in the face. in the end, it's a stylistic issue and to each
their own. just like how you put the body brace on the same line as the
ending parenth of the function rather than on it's own line. :)

i'm not arguing style. again i say, repeat that to yourself until it sinks
in.

function foo ($a, $b, $c ..... lots more
$x, $y, $z) {
return true;
}

And BTW, if my SQL clause gets too long, I do it the same way.

imagine that!

and i bet you do the same when defining arrays, right? ask yourself why.
probably because it is more legible and maintainable, right? if the only
time you do this is when the function's params are way in the right
margin, forcing you to scroll to see them all...essencially screen space,
i think i'll but a gut.


Nope. I do arrays similar to the rest.

'nope'? 'similar to the rest'? so, 'nope' is really 'yep' since i suggested
both one-lining params *and* columnizing them...just as you explained you do
in your example above. are you just being disagreeable today? at least
disagree with me! not agreeing with yourself, aside from looking silly, just
isn't profitable for you.

for the same reasons you should format sql, you format any other
language you write in. i'm sure you've written lots of scripts that are
over several hundred lines. why would you approach writing sql any
differently than other language? just curious jerry. if you have no
other explanation than what you've stated, you've hardly made a
case...except a 'special case' which is therefore, a logical fallacy.
I never said you shouldn't format SQL. I said the way you did it is
stupid.

wow! i should have gotten 'stupid' from "I don't agree with your
method..."? i'm really going to have to read your posts with a lot more
inferencing than is normally due any other human being. that is, unless
you are saying it is stupid now...as opposed to "i said...".


Well, that's what I think about your formatting method. It wastes all
kinds of screen space, making it much harder to see the big picture.

hmmm, i've never heard that about my queries before. quite the opposite. as
i'm not averse to screen space usage, it's not a big deal to me. further,
were it, i'd use a code folding editor.

as it is, i couldn't give two rats asses whether you approve of my
formatting. that is NOT what i've been discussing. do you get that yet?

likewise, rather than bash the way i format sql, wouldn't it have been
more helpful to address the point of FORMATTING sql - which was my point
to begin with. further, providing an example of the way YOU format sql
would have expanded the topic for the op. hell, i may even side with YOUR
version of formatting sql v. the way I format mine. but, simply leaving
it at 'your way is stupid, you're an *** and senseless for
disagreeing with me' doesn't really help anyone...or, your cause - which
i have yet to figure out here yet.


I did address the point.

no, your point was that you disagree with my method. that could be
formatting or style. since you can't grasp that my point was formatting, it
is easy for you to think you've addressed the point. the only time you
actually glanced the point was when you said you do encourage formatted sql.
fine, discussion over. we agree. as to style? i don't care.

And I did provide an example. But when you promote poor formatting
practices, I'll call you on it.

poor in the eyes of jerry stuckle. you objection is saying that it takes up
too much screen space. i've added many descriptives of individual benefits
to my stylization/formatting. you have yet to counter any single one of
them. there's a good debate were you to do so. name calling and slander
('promote poor formatting practices') without a cite to back up the premise
is hardly an engagement at all. are you going to 'recurse' or are you going
to counter? i'm not interested in your current vein...a non-opinionated,
supported counter would be nice about now.

call me on it with fact, jerry. if i want to entagle myself in a stylistic
debate, fact will be my only lure. as it is, we agree on the value of
formatting sql statements. that was my point in all of my responses. get
over it.

But like anyone with no argument, you keep trying to put words into my
mouth.

wow jerry, i've been stating MY case. i've not even addressed any of your
points. look at your ONE, SINGLE POST in this thread. what POINT (much
less points, plural) did you actually make? you said you disagree with
me. that's fine. i simply added more reasons for you/anyone to understand
why i and others do things the way we do.

so please, quote me and the words you are proposing that i'm putting in
your mouth.


You stated that I advocated no formatting of the sql statements. That is
not what I said. Go back and read.

i did.

topic == formatting sql NOT how STEVE formats sql. since the topic was
countered by you originally as 'i don't approve of your method of
formatting', it is logical that that sentence looks incomplete...completed
with 'sql statements'. that means to me, you don't advocate formatting sql.
otherwise, i'd just have said i don't care if anyone approves of how i do
it, just that it is done. and that would have been the end of the
discussion.

you've since described my formatting style as senseless, stupid, and lousy.
good on you! i couldn't care less...nor does anyone else here. at least
those adjectives alerted me to the fact that you didn't get my point, or
didn't want to acknowlege it - formatting sql == good.

i hope you are not projecting on me here from some other thread where
some other person has bashed you. as you know, i have no beef with you.
and throughout this thread in rebuttal with you and darko, i've been
unusually polite. hence my puzzlement of being called an ***,
senseless, and stupid. how did i get your ire up so?

No, I'm addressing you and what you said.

not very well. you glanced over my whole point in a frenzy of 'your way of
formatting sql statements blows...but oh yeah, formatting sql is in fact a
good thing to do'. where everything after the elipses is about
font-size:6.25...and subscript at that! formatting sql statements, jerry.
repeat it, rinse, then repeat it again. that's my point. any other tangent
you've brought forth is not a concern of mine as it all revolves around
opinion and stylistic tastes...unless again, you can give cites - however,
you don't seem to want to actually debate...just toss ad-homonyms about.

whatever.


.