Marek Lewczuk <newsy@lewczuk.com> writes:
> On Apr 5, 2004, at 2:03 PM, Gavin M. Roy wrote:
>
> > I'm one for using base64 encoded text in a text field. It's easy to
> > deal with queries, it's easy to deal with spitting out images, and
> > it's easy to back up. Others do it differently, there are many ways to
> > skin a cat, and each person who skins cats most likely thinks their
> > way is best. Gavin
>
> Anyone knows what about performance of that kind of solution. Right now I'm
> storing all multimedia files on the disc, but I would be great if all files
> could be stored in DB (automatic remove, portability etc...). But the problem
> is with the size of all files - today it is about 5GB, so I belive that this
> can affect for overall DB performance. Any experiences ?
Well just having them in the database won't affect performance directly.
But there are indirect effects:
1) If you're accessing them regularly then the disk data will be cached by the
kernel just like other tables, and will contend with the much denser data
from your data tables.
2) Backups and restores will have to slog through that data as well and take
correspondingly longer.
> PS. My DB have 3 schemes where about 1 million different data are stored. I
> thought that it will be the best to create new scheme for storing files ?
> Right ? How about perfomance in this case ?
Schemas don't affect performance at all.
If you're debating between storing in the same table versus new identical
tables there could be pros or cons, but if it complicates your SQL it's
probably not worth it in any case.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
