![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Darren New" <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Darren New" <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |