PC was a standalone server (not sure what size) running SQLServer.
It choked hard.

There is one thing I have found, heck I've done it myself :), that can
really mess up performance in SQLServer -- the lack of indexes.

With "classic" IO, if you want to find all the orders for a customer,
you'll have an index on the order table by customer. Or if you want to
find the order lines for an order, you'll (obviously) have an index on
order-detail by order, line#. This is all because in classic io you
don't tell the system what data you want, you tell the system how to get
it. Basically your RPG tells the system, go open this index (logical
file) and position yourself in the keys to this key (order 12345) and
then read rows until you hit a different order #.

In SQL, as you know, you don't tell the system how to get data, you tell
it what data you want, it's up to the system to figure out how to get
the data. Therefore, there is no _need_ to have any indexes other than
the one to support the primary key, and you don't even have to define a
primary key. Now, of course, if you want it to perform well, you'll need
indexes, but the existence of indexes and their use as an access method
are completely left out of the domain of the programmer.

Therefore, if you load a table with 50 rows both system will fly, the
System i because it's got the indexes, and the SQLServer system because
it doesn't need any indexes to read a table w/50 rows. (In fact, even if
they were there it wouldn't use them, faster to just read the table
(physical)). Now, load it with 1M rows, the System i will still fly
because the indexes are there, but the PC will choke because it has no
indexes.

-Walden


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].