Re: [Bug-gne]API

[Hook]

Tom Chance wrote:


> >I've clearly not been keeping up here.  Are images going to be inside the
> >database. If so why? Do you know the performance hit that this gives?
Large
> >blocks of text are the same.  MySQL can handle both, but that doesn't
mean
> >that it *should*.
> >
> >Surely keep the database for simple stuff (author details, article
titles,
> >synopses, dates, versions etc) and the bulk data elsewhere.
> >
> >Like I said, if this has already been set in stone, sorry for not paying
> >attention, and could someone post/point me at the argument please?
>
> What's been decided for the moment (but is by no means set in stone) is
> that images will all be stored in folder, not in the database, and all the
other
> textual information (title, synopsis, body etc.) will be stored in the
database(s).

The body of large articles too? Oh well, it's not my system. Be aware
though, that once the API gets designed you may end up locking the database
structure into something pretty close to what you're proposing now, and
after 6 months or so, you might find excellent reasons for redoing the
schema. That always has fallout which affects all the scripts which access
the data. It could be expensive.

> Oh and by the side, could you clarify your idea of slaves+master db
servers?
> Did you mean that you would have one master server which people would
> add articles to, and then a couple of slaves which it would be
copied/recplicated
> to, and then when people make select() queries they select from the
slaves? Or
> did you mean that there would be a backup machine which would every 12
hours
> tarball it's contents for other machines to take the info from?

The former. Trying to produce a tarball from a running database is a
non-starter, the only thing that you'd get is corrupt tables (the index data
would always be in memory rather than on disk). You can get replication to
be real time, and it gives you a lot of resilience at very little cost.

The Hooker