[thelist] redesigning a huge database

Rick den Haan rick.denhaan at gmail.com
Wed May 10 05:37:46 CDT 2006


Hi All,

Our company has been approached to rebuild a rather large and often-used
webapplication, and I've been charged with putting a plan on paper before
any actual work is done.

This application is currently designed to work for dutch customers only, and
all text is hard-coded into the php files. However, our client wants to
expand further out into Europe, which means the application has to be
modified so one or more (preferable one) files with language-definitions can
be used. That's not the reason we're rebuilding it from scratch, though.

Currently, *everything* is stored in the database. From the moment you open
the app, PHP sessions are stored, and every movement and action up until you
close your browser is logged in the database. Don't ask me why, they
explained once and it made sense, but I forgot. The trouble is, it's been up
for roughly two years now, and there are tables in there with over 400,000
records. There's another one with more than 700,000 records. And this is the
Netherlands, only.

Part of the application depends on a SELECT DISTINCT mysql-query, and that
takes far too much time right now (up to the point where the app hangs). So
the database desperately needs to be redesigned for expansion into Europe.

Has anybody had any experience redesigning databases of this size, and can
you give me pointers on what to look out for? One of the guys here said that
perhaps it's a good idea to have multiple databases, which is indeed a
possiblity, as it's hosted on a dedicated server we have full control over,
but is that a good idea?

Rick.



More information about the thelist mailing list