List:General Discussion« Previous MessageNext Message »
From:Martijn Tonies Date:September 22 2005 9:31am
Subject:Re: good database design
View as plain text  
Hi,

> > 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.

Which is what I said :-)

> 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).

Obviously, the MySQL guys should be bugged about this...

> > 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...

Did you read my paragraph about throwing hardware?

No offence, but I stated several times that the logical data requirements
should come first, in design. After that, tweak the server, after that, if
possible, throw more hardware at it. Now, if this doesn't cut it, you might
get into denormalization or other things that make your application run
faster...

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

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