Subject | Re: Newbie: Query speed and DB size |
---|---|
Author | Adam |
Post date | 2008-03-27T11:05:38Z |
--- In firebird-support@yahoogroups.com, "kogerbnz" <kogerbnz@...> wrote:
hardware regardless of table size.
pieces of data from different tables one at a time with different
queries? The missing piece of that jigsaw would be the concept of a
'join'.
http://en.wikipedia.org/wiki/Join_(SQL)
Good primary keys should have no real world meaning. They are simply
'database plumbing' that ties rows from different tables together via
foreign keys. It is unusual to run a query to select only the primary
key field, so perhaps it may help to explain what you are trying to do.
Adam
>Well this will be quite fast, probably under 10ms on typical desktop
> Thanks for your answer, also thank you Adam!
>
> I'll try to give you the missing pieces.
>
> > > 1) Does the query speed depend on the number of rows in a table?
>
> > Does you query specify criteria where all the columns are indexed?
> Yes
>
> > How specific is the value being searched for?
> Very specific, I'm querying on the primary key, so the result would
> always contain one row.
hardware regardless of table size.
>like
> > Does the query need to evaluate across indexes?
> No
>
>
>
> > > 3) OK, I know this is a vague question.
> > > On a "normal" desktop computer say 2MHz and 2GB RAM or something
> > > it. How many simple queries (like select * from table) can Imake in a
> > > second. Is it in the 100's, 1000's etc.?What you are doing sounds a bit odd to me. Are you attempting to fetch
>
> > Simple queries like that are no measure of anything in real life!
> > How many columns are there? How big are the records?
> >
> > Is the HD: IDE, SATA 1.5Gbps, SATA 3.0Gbps, SCSI, SAS 10K or SAS 15K?
> >
> > Is there a RAID controller? Does the RAID controller have cache?
> >
> > Is the PC running Windows or Linux? What is the file system of the
> > drive/device that the database is stored on?
>
> Windows, IDE HD, no raid, and of course not 2MHZ CPU ;-)
>
> I'm not expecting an exact answer, I'm just trying to get a little
> feeling with how the DB would perform.
> Which would guide me when deciding if I should try optimize my design
> to use fewer queries, but giving a bit messier table design.
pieces of data from different tables one at a time with different
queries? The missing piece of that jigsaw would be the concept of a
'join'.
http://en.wikipedia.org/wiki/Join_(SQL)
Good primary keys should have no real world meaning. They are simply
'database plumbing' that ties rows from different tables together via
foreign keys. It is unusual to run a query to select only the primary
key field, so perhaps it may help to explain what you are trying to do.
Adam