Brent Baisley wrote:
> There will always be new requests, but many times you can store data
> "vertically" in rows instead of "horizontally" in columns. You would
> need a "label" column to indicate what type of data the row contains.
> It's more work on the front end, but a lot more flexible. It's a
> technique I use often, but may not be applicable/possible in your
> situation.
That is right, but wouldn't make the large table even larger ?
>
> You can't create indexes to avoid or reduce full table scans?
>
The major problem is that the application needs fast selects (for
displaying information) _and_ fast inserts/updates/deletes (data is updated
regularly with some large upload sets). So at the moment it isn't possible
to use more indices.
> InnoDB is slower in certain respects, but you need to keep in mind that
> InnoDB will allow multiple things to happen at once. Massive deletes can
> be a problem in InnoDB, taking a loooong time.
> Depending on how your data is structured, you may want to look into
> merge tables (MyISAM). I've got a "table" with almost 250 million
> records in it, which is a rolling 6 months worth of data. Once a month
> we need to "delete" a months worth of data (millions of records). We
> make sure that each of the underlying tables of the merge table are
> about 1 months worth of data. To "delete" we drop the table and alter
> the UNION on the merge table. Takes less than a second.
>
> Delay key write won't help much if you are not using indexes.
If will try that first and see if it speeds up the writing operations.
Thanks for your valuable input, I'll report back what happened :-).
Bye
Racke
--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
