![](/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) |
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
|
![](/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: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
|
![](/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:
> 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
|
![](/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: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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |