Hit Summaries
От | Jonathan Bartlett |
---|---|
Тема | Hit Summaries |
Дата | |
Msg-id | Pine.GSU.4.44.0301271050090.556-100000@eskimo.com обсуждение исходный текст |
Ответ на | Can object oriented table design help to solve this problem? ("Alan T. Miller" <amiller@hollywood101.com>) |
Список | pgsql-general |
What I do for such tallies is create a table similar to the following: create table activity_log (object oid, activity oid, activity_time timestamp) With an additional summary table: create table activity_summary_log (object oid, activity oid, month int, year int, instances int); Periodically, I summarize my tallies into the summary log: insert into activity_summary_log (object, activity, year, month, instances) select object, activity, extract(year from activity_timestamp) as year, extract(month from activity_timestamp) as month, count(*) from activity_log where extract(month from activity_timestamp) < extract(month from CURRENT_TIMESTAMP) group by object, activity, month, year; followed by (in the same transaction) delete from activity_log where extract(month from activity_timestamp) < extract(month from CURRENT_TIMESTAMP) Then to get all my summarized data (even the ongoing tallies), I have a view which grabs from the summary tables and summarizes the activity_log table. I like this setup because: a) If my summarizing script doesn't function, I haven't lost anything. I just run it again when I feel like it b) If my summarizing script is called too often, it's fine c) I can record additional information about each transaction in my activity log for audit purposes, which get automatically removed when I summarize everything Jon On Sat, 25 Jan 2003, Alan T. Miller wrote: > I have a farily general question about structuring a database, and > considering this is the 'general' mailist for postgresql my database of > choice for the project I am working on, I thought this would be a good place > to start. Please forgive me if this should be posted elsewhere. Of course a > hint on where it should be posted would be great if this is not the correct > place to ask this. > > Anyway, I am trying to come up with a logging table scheme for an > application that indexes rental properties around the world. Currently we do > not have anything in place in our current database tables to keep an > accurate ongoing tally of the hits each of these properties gets on any kind > of time interval. > > What I do have is a table that keeps a running total for each property. The > way that is implimented is through a javascript function that makes a > request to a script that then updates the database table containing a unique > id for that property and then ups its count for each hit. So we have a table > that looks like... > > TABLENAME: Hits > TABLE COLUMNS: ID_Property | hit_total | last_updated > > However, we want to expand this and be able to keep a running tally of hits > per week, month, day perhaps. But I am having trouble wrapping my head > around the best way to go about doing so. A sensible table scheme escapes > me. > > My first inclination was to create a table as follows... > > TABLENAME: Weekly hit total table > TABLE COLUMNS: ID_property | week 1 | week 2 | week 3 | week 4 | etc... > > That table would be populated via an automated script that would tally up > the weekly totals for each property based upon the number of hits drawn off > of a modified version of the hits table described earlier. In other words, > the current hit counter table would be cleared every week to make way for > the tally to start fresh for the next week. > > The problem with the above scheme however is that I would be adding a column > to the table every week, and it just seems like bad design to do so. There > must be a better way. > > To avoid having to create a table that requires that I alter its structure > every week, I thought of the following solution but It seems overkill, as it > would add a huge number of tables. Anyway, this scheme would have a seperate > table for each property with a structure something like the following. > > TABLENAME: Hit Totals for Property 'foo' > TABLE COLUMNS: Week | weekly hit total > > For every week there would be a new row added to the table, again, it would > be populated by a cron script. However, I do not like this solution as I am > not interested in having 5000 tables set up for all the properties, and then > each time one of the properties were added or deleted I have to alter the > database to add or delete tables. > > to sum it up.... > > Solution 1 which provides a unique row for each property, seems inadaquate > because it will require adding columns to the database on each update, thus > altering the table structure on a constant basis. > > Solution 2 which provides a unique table for each property in the database > seems inadaquate for the same reason as above, I am altering the database > itself all too often, not to mention I have to deal with thousands of > tables. > > Considering postgreSQL is an object oriented database, and I am new to that > concept in databases, I was hoping maybe someone here had a workable > solution or suggestion that may or may not take advantage of PostgreSQL's > object oriented features. Any help or suggestions on this would be very > highly appreciated. > > Thanks, > Alan > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
В списке pgsql-general по дате отправления: