On Fri, 28 Jan 2005 11:47:47 +0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Jacob Friis Larsen <[EMAIL PROTECTED]> wrote on 28/01/2005 11:23:46: > > > We have a table that grow by 200MB each day. > > > > Should we put data in different tables or is one big table just as fast? > > We will for new data do select, update and insert and for old data > > only select. > > It is not possible to answer in the general case - you would need to > explain more about your table and usage patterns.
The table contains data from RSS and Atom feeds. Most users only need to see the newest items. A select could look like this: "SELECT title, desc FROM items WHERE feedid = 25 LIMIT 10" > However, if you can use MyISAM tables, you should at least consider using > MERGE tables: > http://dev.mysql.com/doc/mysql/en/merge-storage-engine.html I will. > If your database is "well indexed" and your searches can generate > relatively small amounts of data on the first key used, the overhead of > having enormous files is small. At the other end, if the MySQL is reduced > to a linear search, the impact of a huge file is enormous. I'm not sure I understand this. > If most of your SELECTs are on "recent" data, it is work considering > splitting the table into daily, weekly, or monthly sub-tables. This means > that you can archive very old months, and pack recent months, while > keeping only the current month active. But if you need to search the > entire archive frequently, this will reduce performance. I only need to go through the entire archive when indexing via Swish or when Google stops by. Thanks for your help. Jacob -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
