Subject | Re: [firebird-support] Large record count - will it work? |
---|---|
Author | Aage Johansen |
Post date | 2009-02-17T20:26:39Z |
Kjell Rilbe wrote:
position where you cannot really fine tune the queries. This may be
the case for any db system, and I don't know ECO at all. Just a
faint recollection of someone having problems with generated SQL
which were not optimized well (don't remember which db server).
Maybe you should look for faster disks. There are 15000rpm disks
around, but maybe not of the SATA variety (we use 15000rpm SCSI disks).
--
Aage J.
> Hi,If ECO generates Firebird-unfriendly SQL you may find yourself in a
>
> We're starting work on a data registration and maintenance system that
> will be built with C# and ECO (www.capableobjects.com). ECO is an MDA
> framework, which includes an OR mapping.
>
> Firebird would be our first choice for DB backend simply because it's
> the only free DB server I'm familiar with, and I'm pretty fond of it.
>
> My main concern is that this system will have to track full history of
> all data as well as keeping track of exaclt what data items have been
> delivered to which customer and when.
>
> This large log can potentially grow with some 100 million records per year.
>
> Would this be a potential problem for Firebird?
>
> We can purge data that's older than X months, where X can be just about
> anything from 3 and up. We can even purge ad hoc, when needed, i.e. when
> the server starts to become slow or something. But we'd like to keep as
> much history as possible.
>
> The SQL used will mainly be autogenerated on the fly by ECO. We can add
> indexes manually if needed, in addition to those autocreated by ECO.
>
> Anything else we should be aware of, consider, etc?
>
> It will all be deployed on a Win2008 Server 32 bit with IIS 7. I think
> the harddrive is a regular 7200 rpm SATA. 3 Gbyte RAM.
>
position where you cannot really fine tune the queries. This may be
the case for any db system, and I don't know ECO at all. Just a
faint recollection of someone having problems with generated SQL
which were not optimized well (don't remember which db server).
Maybe you should look for faster disks. There are 15000rpm disks
around, but maybe not of the SATA variety (we use 15000rpm SCSI disks).
--
Aage J.