> But I reserve the right to continue to be irked when I have to take my 
> beautiful code and litter it with statements to turn the numbers backwards 
> at the start,

If you had them round the right way to start with you wouldn't need to 
litter your code with anything :-P

Post a reply to this message

scott wrote:
>> But I reserve the right to continue to be irked when I have to take my 
>> beautiful code and litter it with statements to turn the numbers 
>> backwards at the start,
> 
> If you had them round the right way to start with you wouldn't need to 
> litter your code with anything :-P

Take the MD5 hash kernel, for example. Essentially you're supposed to 
load a word of data from the current block and mix it into the hash state.

Except for the minor detail that you can't just *load* it, you have to 
turn it backwards first, or you'll get the "wrong" answer (i.e., not the 
answer listed in the MD5 spec). It's not that the data you're trying to 
hash is backwards, it's just that MD5 is defined to operate backwards. 
Except, of course, that working completely backwards would be 
comparatively simple; no, MD5 is defined to work on words forwards, but 
each word must be written backwards. *sigh*

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:4ae76041$1@news.povray.org...
> Captain Jack wrote:
>> Technically, in T-SQL, that would be a CROSS JOIN. JOIN all by itself 
>> defaults to a LEFT INNER JOIN, for which the results could vary.
>
> Actually, I thought you couldn't do JOIN all by itself at all. Every JOIN 
> has to be part of a SELECT, right?

Sorry... I meant to say "JOIN without a qualifier" rather than "JOIN all by 
itself". A JOIN clause always follows a FROM clause (essentially acting as a 
binary operator on two tables, creating a complex FROM) and the FROM has to 
follow a query directive like SELECT.

I always think of SQL as a weird language, but I guess English is a tad 
weirder. :D

Post a reply to this message

Captain Jack wrote:

> I always think of SQL as a weird language, but I guess English is a tad 
> weirder. :D

Just a tad, yeah...

Post a reply to this message

Captain Jack schrieb:

> SELECT C.Name, U.UserName
> FROM tblClients AS C
> OUTER JOIN tblUsers AS U ON U.UserId = C.LastEditUserID
> 
> In that case, the column LastEditUserID is zero (another way of logically 
> saying Null, I s'pose) when the client row is new and has never been edited. 
> I do that so that in that query I always get the client data, with the user 
> name being optional.

In theory, you'd solve this by adding another entry to tblUsers with 
default values to use for new clients.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> wrote in message 
news:4ae9b09e$1@news.povray.org...
> Captain Jack schrieb:
>
>> SELECT C.Name, U.UserName
>> FROM tblClients AS C
>> OUTER JOIN tblUsers AS U ON U.UserId = C.LastEditUserID
>>
>> In that case, the column LastEditUserID is zero (another way of logically 
>> saying Null, I s'pose) when the client row is new and has never been 
>> edited. I do that so that in that query I always get the client data, 
>> with the user name being optional.
>
> In theory, you'd solve this by adding another entry to tblUsers with 
> default values to use for new clients.

Which hikes up my filtering costs later... When I show a list of users to 
select for, say, a report, I have to filter out the "special cases" that 
aren't actually users. I'm effectively making the User table track two 
different kinds of data, and I have to take that into account in all my 
future use of the table. Probably by adding a column to the table to flag 
how it's used. Then I have extra documentation tasks, more maintenance 
problems...

Okay, now I'm whining. Sorry about that... I just got out of a three hour 
design meeting where we ran out of coffee, and my head hurts. :D

Post a reply to this message

Captain Jack wrote:
> Which hikes up my filtering costs later...

Which is why actual production SQL operates with outer joins instead of the 
formal mathematical operations. :-)

Note that relational theory also says rows are unordered and cannot be 
duplicated, neither of which is true of a practical large-scale SQL server's 
data.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:4ae9e0ac$1@news.povray.org...
> Note that relational theory also says rows are unordered and cannot be 
> duplicated, neither of which is true of a practical large-scale SQL 
> server's data.

Certainly not in any of the databases here...

That reminds me of when I first got here and started trying to clean up the 
DB I inherited. I found one of the tables had a clustered primary index on a 
uniqueidentifier type column. There weren't any queries against the column, 
and it wasn't even used in any JOIN's. I s'pose it made sense to somebody, 
somewhere...

Post a reply to this message

Captain Jack wrote:
> There weren't any queries against the column, 
> and it wasn't even used in any JOIN's. I s'pose it made sense to somebody, 
> somewhere...

Makes me wonder why you even had the column, let alone the index.

I once managed a database with no autoincrement columns at all. :-) All the 
primary keys came from the people using the database from outside the company.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:4ae9ea6b$1@news.povray.org...
> Captain Jack wrote:
>> There weren't any queries against the column, and it wasn't even used in 
>> any JOIN's. I s'pose it made sense to somebody, somewhere...
>
> Makes me wonder why you even had the column, let alone the index.

I never did figure it out for sure, but the column was named "rowguid", so 
I'm guessing that whoever created it thought it was required for 
replicating, or something. Replication had never been set up for the 
database, though, so that's about the end of my guesses.

Once I got the front end application cleaned up, it (and a bunch of other 
crappy design problems) went off to visit Atlantis wearing lead coated 
uranium swim fins.

Funny, the performance of writing new records improved after I got rid of 
that column...

>
> I once managed a database with no autoincrement columns at all. :-) All 
> the primary keys came from the people using the database from outside the 
> company.

I've always felt that if we could get rid of clients, vendors, and the need 
for a budget, programming would be a really fun occupation. :D

Post a reply to this message