<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi Denise,<br><br>You also have the option of using a metadata catalogue, such as Geonetwork or CKAN to catalogue the incoming files. I have a colleague who has developed a system to search through a folder of incoming files, containing text, spreadsheets, word docs etc. These are parsed to extract meaningful metadata and a Geonetwork record is automatically created for each new file. <br><br>With a Postgis solution (we have a timeseries database of 350,000,000 records), it is partitioned on year of timestamp, with a clustered index on the timestamp in all but the current partition. This approach could perhaps work well for your application.<br><br>Files on the filesystem, referenced/catalogued by path (or URI) in a timestamped database record. Create a new partition whenever you want to keep the partitions a manageable size.<br><br>If you have a standard query
 that returns multiple "neighbouring" records based on a field (on timestamp for example) then add a clustered index on this field so that you are maximising the hits per disk read.<br><br><br>Brent <br><br>--- On <b>Sat, 3/2/13, Andy Colson <i><andy@squeakycode.net></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Andy Colson <andy@squeakycode.net><br>Subject: Re: [postgis-users] design problem<br>To: "PostGIS Users Discussion" <postgis-users@lists.osgeo.org><br>Date: Saturday, March 2, 2013, 10:44 AM<br><br><div class="plainMail">On 3/1/2013 3:11 PM, Denise Janson wrote:<br>> Hi,<br>> <br>> I have an application that is going to receive lots of georeferenced files<br>> every day. Each file has information of several points. Probably in few<br>> years my application will have a Tera of points information stored.<br>> <br>> I think I can do
 this design  in two ways:<br>> <br>> 1. Two tables, one of “uploaded_files”, and another of “points” (one<br>> uploadedFile to N points). And I'll have to partition the points table,<br>> maybe by month …<br>> 2. Or I can create one table per file, having thousands of tables in few<br>> years.<br>> <br>> Which case is better for my application?  Is there any better way to do<br>> this?<br>> <br><br>If performance is a concern, and the file's are of any meaningful size, you might consider leaving them on the filesystem and have the table point to it (full path name sort of thing).<br><br>Storing the file in PG is possible, and its nice because everything is kept together, but if you have to get to and read the files fast, then leave them on the filesystem.<br><br>The lots of tables approach is problematic if you ever want to write queries that look back in time.  Its much harder to say, give me every
 record from the beginning of time at this point.<br><br>With a good index, PG wont have a problem with a single table containing billions of rows.  Just try to avoid doing bulk operations (like update and delete) on the entire table.<br><br><br>> uploadedFile to N points). And I'll have to partition the points table,<br><br><br>Why will you have to partition it?<br><br>-Andy<br>_______________________________________________<br>postgis-users mailing list<br><a ymailto="mailto:postgis-users@lists.osgeo.org" href="/mc/compose?to=postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br></div></blockquote></td></tr></table>