List:General Discussion« Previous MessageNext Message »
From:Jigal van Hemert Date:September 22 2005 9:18am
Subject:Re: good database design
View as plain text  
Martijn Tonies wrote:
> Given that the OP did not state that there were any issues with an
> existing website, logical requirements come first. Period. No discussion ;)

Logical requirements may come first, but may be overruled later by 
requirements caused by performance issues or system limitations.

If your logic designed a large type of primary key, you may run into 
problems with InnoDB tables. The PK is stored with the data and other 
indexes refer to the PK (and not directly to the data as is the case 
with MyISAM). So a large PK will increase the table size (data + 
indexes) and may thus lead to performance issues when the database does 
not fit in memory anymore, or when the buffers,etc. hit the memory 
limits on your system.

A very complex model may lead to queries with more than 31 JOINs, which 
is not possible with MySQL without modifying the source and recompiling 
it (and even then the limit seems to be 63).

> In any case, if this is a read/write application, I would still say that
> logical
> requirements should go first. If this is a read only application, do
> whatever
> you want.

Logic may come first in the time line, but may be overruled by other 
requirements. Finding people who celebrate their birthday today (or this 
week) may become a very slow task if you only use a logical data field. 
Denormalisation by using extra fields for particular tasks is a 
completely logical solution in this case.

> If this is the customers own server and everything is logical correct but
> there
> are "some" performance problems, I'd say: throw more hardware at it.
> Obviously, this makes sense --after-- tweaks to the database engine caching
> etc etc... Hardware is cheap(ish). If you can control it, do so.

"Throwing" hardware at it is not always a good solution. You know better 
than that. The customer better not find out that the application could 
very well run on the original server with a few "tweaks" as you call 
them, and that he appears to have lost a lot of money for new hardware 
and all the time needed to get the new server running in the 
configuration that you suggested...

Regards, Jigal.
Thread
connect from oracle to MYSQL.Ananda Kumar20 Sep
  • Fwd: connect from oracle to MYSQL.Ananda Kumar21 Sep
    • Re: connect from oracle to MYSQL.Pooly21 Sep
      • Re: connect from oracle to MYSQL.Ananda Kumar21 Sep
        • Re: connect from oracle to MYSQL.Ananda Kumar22 Sep
          • Re: connect from oracle to MYSQL.Pooly22 Sep
            • Re: connect from oracle to MYSQL.Ananda Kumar22 Sep
  • good database designOKAN ARI22 Sep
  • Re: good database designMartijn Tonies22 Sep
    • RE: good database designTim Hayes22 Sep
      • Re: good database designMartijn Tonies22 Sep
        • Re: good database designJigal van Hemert22 Sep
      • Re: good database designDBA)22 Sep
      • Re: good database designMartijn Tonies22 Sep
  • Re: good database designMartijn Tonies22 Sep
  • Re: good database designOKAN ARI22 Sep
RE: good database designSujay Koduri22 Sep
  • RE: good database designTim Hayes22 Sep
    • Re: good database designMartijn Tonies22 Sep
  • RE: good database designGilles MISSONNIER22 Sep
RE: good database designSujay Koduri22 Sep