|
|
Posted by Richard on 06/27/07 13:40
On Jun 27, 2:27 am, --CELKO-- <jcelko...@earthlink.net> wrote:
> I hope you know better than to use GUIDs in an RDBMS except for
> replication, never to use reserved words like "date" for data element
> names or vague names like "type" -- the basic ISO-11179 rules, etc.
> You also seem to confuse fields and columns, but let's skip the signs
> of poor SQL practices for now.
>
Well, yes, I actually do know better. The columns, variables and
tables in the query are renamed as I don't want to post production
code on the Internet. Also excuse the mixup between fields and
columns, I'm not a native English speaker.
One big problem (as i see it, and I'm by no means a SQL expert) is
that the db in question uses uniqueidentifier primary keys with
clustered indexes on those almost EVERYWHERE, and there is nothing I
can do to change that at the moment...Constructs like
FROM z
INNER JOIN a ON ..GUID = ..GUID
INNER JOIN b ON ..GUID = ..GUID
INNER JOIN c ON ..GUID = ..GUID
INNER JOIN d ON ..GUID = ..GUID
LEFT OUTER JOIN eON ..GUID = ..GUID
AND VERSION = (
SELECT MAX(VERSION) FROM f WHERE ..GUID = ..GUID)
make the queries run painfuly slow.
So the question is, is there ANYTHING I can do to optimize this type
of queries or is a redesign the only thing that would help?
@Erland:
I use MS SQL 2000 server and @date is a local variable =)
Navigation:
[Reply to this message]
|