This seems to me to be more a question of program architecture than of implementation. Being about 2 years of full time perl programming in, I try to think about my data structures first before I design the code. Given that you are taking input from planes, ships, earthquakes, weather, etc. the DATA MODEL that will be the core of your design - and persistent data store should be a single table of all of the common factors - lat, long, time - and some "type" that uniquely specifies the special rendering of that item. KISS! Two things come up here - this is a single table - probably 2-D. And you can implement the VIEW as a set of queries on this table (row by row?) - with specific routines to render the different types. I am struggling to think of a better conceptual way to do this than: SELECT name, type FROM global_data WHERE lat = 45% # ie iterate row by row AND long = 15% AND time < 28 days SORT BY time DESCENDING into two arrays @event_name = []; @event_type = []; ... err and just display item '0' from the array (you can ony render the top / most recent). Icons, colours etc can be chosen to reflect you desired view. Then you can build filters that get / scrape data to load the table and that display data according to its type. So - even if you did not have any SQL experience, I think that this would be the first port of call to help Structure your Query. And then I would bear in mind that this needs (i) One well designed table (ii) No transactions, not performance limiting, no indexes And, of course, great DBI implementations and MySQL for PCs, Linux, etc, etc.