Subject | RE: [firebird-support] optimizing table size, is it worth it? |
---|---|
Author | Alan McDonald |
Post date | 2009-04-25T01:10:57Z |
> I am new both my employer and the database they use, Interbase. I knowwell that's wrong. dunno who told you that. Put the correct indexes in, use
> this is a Firebird forum, but I tried posting to the Borland newsgroup
> yesterday and than realizaed this morning that it is not very active,
> no posts in like two months! So I found you all. It is my
> understanding that Firebird is the open source of Interbase, so I hope
> I am not out of line asking this question:
>
> We are using Interbase 7, I have heard from co-workers that as the
> database grows in size (300M to 400M), performance really takes a hit.
sensible queries and performance is always excellent.
> I am currently adding a whole new feature to the application, so I willno, forget that as a strategy.
> be adding a bunch of new tables.
>
> I am wondering... Is it worth while to optimize tables to fit into
> pages? My thought is that if you had a simple table:
>again, forget all this.
> id integer
> name char(10)
>
> Rather than leave the name at 10 char's, round it up to 12 so the table
> is 16 bytes and will fit into a sector nicely. The only catch is that
> all the tables will have varchar's of lengths over 50 most of the time.
> Would that null and void such an optimization or not? Here is an
> example:
>
> id integer
> name char(40)
> desc varchar(60)
>
> My thought is that by rounding the desc up to 84, that will make the
> table max out at 128 bytes, and again always fit nicely into a page.
>no. placement is meaningless. I have these fields in all tables.
> Also, does placement of varchar's have a large impact on preformance?
> In all my tables, there is a updatedby, updateon, insertedby, and
> insertedon field. Should these fixed length fields always come before
> variable length fields or will the engine do that automatically?
>yes, always keep you eye in the sorts of queries to be used. wherever a
> Are there things I should be keeping in mind as I create new tables to
> help performance?
WHERE clause is to be used, put an index on that field (as a general rule),
but do some query analysis if in doubt. Most admin tools now have query
analysis so you can see if a query is costly and adapy indexes accordingly.
More specific questions here will elicit more specific answers.
Alan
>
> Cartoper
>