You may want more indexes but you might be getting killed because you already have too
many.
To test - try loading into a table without indexes and see if it makes a difference.
At the very least - check to see if the primary index which starts with 'dic' can make
your special 'dic' index
Michael,
You are right - the cycle savings are minimal - usually because once the GROUPing is
done - there aren't very many rows to be returned and sorting a few hundred of even a
few thousand of them is pretty instantaneous.
It's really mostly philosophical - when you only specify GROUP BY -
Guys - I think this fusing of GROUP BY and ORDER BY is a bad thing - even if it works.
GROUP should group and if you want an order - add an ORDER clause explicitly. Yes, the
GROUP BY does a sort and you are tempted to leverege it but it could lead to problems.
It may not be visible in
What I was saying was - everything slows down when it gets bigger. However, a lot of
work has been put into database engines to keep them going fast even when they get
big, whereas file systems slow down considerably when they get bigger.
It's not the storing of the link that's the issue.
Luis - you're quite polite so I'll assume that you are ignorant rather than prejudiced.
You have a university email so I'll also assume you're a student who wants to learn.
So here's your lesson for today: Don't judge people by their cover, or by their color,
or by their name, or by their
Another perspective on the subject of BLOB vs. Links.
Links are easier to implement and may be an OK way to start. However, a file system is
really a crude database, and I emphasize crude. It's not very good at handling high
transaction rates, access from multiple machines, or volume.
If your
As everyone has mentioned - you should always assume the data comes back randomly -
even if the table is completely static and there have been no inserts or updates, but
it's even more subtle than that.
When you port your application to a database than allows your queries to run
multi-threaded
I am not sure about MySQL but in Oracle this will NOT work: SELECT A AS SortCode,
* FROM Jobs
However, this WILL: SELECT A AS SortCode,
Jobs.* FROM Jobs
Try adding the table or alias in front of the *.
In general, however, I will repeat my
You might consider a whole different approach which is more efficient, because
regardless of VB or MySQL - in your current setup you are issueing 3 distinct SQL
statements against the same table and you might be able to convert it to only issueing
one.
Basically, use functions to create 1's or
Chris,
We run a large data warehouse with tables similar to yours. We basically gave up on
indexing and the overhead involved and just tablescan. The key is to partition the
data using a concept called Merge Tables. However, since we currently use Oracle,
eager to migrate to MySQL - I don't
The fundamental reason for using stored procedures is performance.
Stored procedures are compiled code. This means the database has reviewed the SQL,
came up with the most efficient plan of action (often sorting through thousands of
permutations when multiple table joins are concerned), and
11 matches
Mail list logo
