scott wrote:
> 
> when people do write out numbers 
> they are *right justified* 

Not really.

  3.44444
      4.5
    34424

is right justified as I understand it, but that wouldn't be helpful when 
adding them up.

  2.0
02

I see this more as being fixed into a grid padded with spaces on one 
side and zeros on the other. Doesn't matter which side is padded which 
way or if both are the same.

  -Shay

Post a reply to this message

SharkD wrote:
> There are three types of joins. 

There's one kind of join in relational theory. There are three or four kinds 
of joins in SQL, each of which is a join followed by a select.

I.e., inner join isn't like an intersection. It's a cartesian join, followed 
by a select where the key from the first table matches the key from the 
second table in the result.

Outer joins are peversities caused by people not normalizing columns that 
can have NULL in them. If none of your tables can have a NULL, you never 
need an outer join.

If it was an intersection, you'd never get any rows, because you wouldn't 
have two tables with identical rows in them.

-- 
   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:4ae75b04@news.povray.org...
> I.e., in relational database theory, a join gives you each row of the 
> first table concatenated with each row of the second table. Then you 
> select the rows where the keys are equal, then you project over the rows 
> you actually want. Those are the three basic reading operations in 
> relational theory. The only reason "inner join" and "outer join" exist is 
> that people don't want to actually normalize their databases the way that 
> works well with relational theory.
>
> SQL kind of weirds up the syntax some, but that doesn't mean you should 
> use an entirely different (and incorrect) word for the operation. :-) If 
> you're going to ask for a different word, ask for one that doesn't mean 
> something wrong. :-)

I do sometimes miss the old days where I had a separate disk file for every 
type of data, multiple record formats with different numbers of fields and 
types of data in every file, even more separate files with indexing 
information that had to be kept in sync by the same code that acted as the 
application front end, manual locking of records and files and--

Hmm... actually, I don't think I miss that at all, come to think of it.

:D

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:4ae75bb2$1@news.povray.org...
> Outer joins are peversities caused by people not normalizing columns that 
> can have NULL in them. If none of your tables can have a NULL, you never 
> need an outer join.

Hmm... I use outer joins for optional data a lot, without respect to nulls. 
Like this:

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.

I'll be the first to admit that DB management is not my strong suit, though.

Post a reply to this message

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?

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

Post a reply to this message

On 10/27/2009 5:03 PM, Darren New wrote:
> Actually, I thought you couldn't do JOIN all by itself at all. Every
> JOIN has to be part of a SELECT, right?

It doesn't just have to be SELECT. But it has to be one of the other 
commands, UPDATE, INSERT, etc.

Mike

Post a reply to this message

>> when people do write out numbers 
>> they are *right justified* 
> 
> Not really.
> 
>  3.44444
>      4.5
>    34424

OK smartass :-) You line up the decimal point if not dealing with integers.

Anyway, you still work from the LSB first when doing anything with them.

Post a reply to this message

scott wrote:

> Anyway, you still work from the LSB first when doing anything with them.

When was the last time *you* did long-division? :-P

Post a reply to this message

>> Anyway, you still work from the LSB first when doing anything with them.
>
> When was the last time *you* did long-division? :-P

Hehe, not since doing it with polynomials at university.

But since then I was messing about with writing an unlimited precision 
integer program, implementing the +,- and * by hand.  I dunno, it just 
seemed the obvious thing to do to put the LSB of the number in array 
position zero, putting the MSB in position zero would have made things quite 
awkward.

Post a reply to this message

>>> Anyway, you still work from the LSB first when doing anything with them.
>>
>> When was the last time *you* did long-division? :-P
> 
> Hehe, not since doing it with polynomials at university.
> 
> But since then I was messing about with writing an unlimited precision 
> integer program, implementing the +,- and * by hand.  I dunno, it just 
> seemed the obvious thing to do to put the LSB of the number in array 
> position zero, putting the MSB in position zero would have made things 
> quite awkward.

Well, clearly I'm not going to win this one because I am apparently the 
*only* person here who thinks this is a very, very bad idea. 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, and then turn them back round the right way 
again afterwards, just because somebody somewhere decided to design 
their cryptosystem to follow Intel's broken design. :-P

Post a reply to this message