> Jakab Laszlo wrote:
> > Hello Chris,
> >
> > I mean here 150000 inserts/day ( quickly grows constantly )... - with
> > transactions and on the same table ... maybe after one significant
> > amount of time we can move the records of one year to one archive table
...
> > And some 2-3 millions of selects / day ...
>
> That's no problem at all, depending on:
>
> + How complex are the queries you're intending on running?
> + How will the data be spread between the tables?
>
> + The amount of data per row also makes a difference, if it is
> extremely large.
>
The main information is a barcode. The big table will have aprox 3 fields
(just id type fields).
Not so complex there will be mainly about 50 tables with all the info
totally normalized and with some around 10-20 tables which make the links
between them. Usually the join is starting form one much smaller table and
with left join goes trough the big table (barcodes) and maybe also on other
tables.
And then this table with barcode (this is the bigone with 150000
records/day) linked to other smaller tables. ( 1 bigger with aprox 7000
inserts/day).
> > I would like to know also some hardware related advice.
>
> You're almost definitely going to be needing a SCSI or better RAID
> array, plus a server with quite a few GB's of ECC memory.
Unfortunatelly the hardware budget should be keept as low as possible.
I was thinking is there could be reliable solution based on dual processor
and ATA 133 raid mirroring normally with some gigs of memory.
Thanks,
Jaki