Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function
От | Lennin Caro |
---|---|
Тема | Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function |
Дата | |
Msg-id | 627796.747.qm@web59510.mail.ac4.yahoo.com обсуждение исходный текст |
Ответ на | Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function (APseudoUtopia <apseudoutopia@gmail.com>) |
Список | pgsql-general |
--- On Mon, 6/29/09, Tguru <guru@talend.com> wrote: > From: Tguru <guru@talend.com> > Subject: Re: [GENERAL] Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function > To: pgsql-general@postgresql.org > Date: Monday, June 29, 2009, 1:33 PM > > To migrate the site, you can use an open source ETL tool. > > Talend Open Studio is an open source ETL tool for data > integration and > migration experts. It's easy to learn for a non-technical > user. What > distinguishes Talend, when it comes to business users, is > the tMap > component. It allows the user to get a graphical and > functional view of > integration processes. > For more information: http://www.talend.com/ > > Justin-95 wrote: > > > > > > APseudoUtopia wrote: > > > > thread, then logs out (intending to > read all the other forum threads > > at some point in the future when they log in again). > If I used a VIEW, > > it would automatically consider all those unread forum > posts to be > > read when the user logs out. > > > > > > That wouldn't work. What if a user logs in, reads only > one forum > > > > > > You are keeping a list of all the forums a user has > read, i would not > > worry about making sure the table tracking user > activity has duplicate > > key values. The select can be limited to return just > on row with the > > highest time stamp then compare this result to figure > out what forms > > the user has not read yet. This eliminates one of > problems but creates > > a problem where table tracking user activity is going > bloat but in low > > traffic times delete the duplicate values. > > > > A similar topic was discussed on the performance > mailing list, where > > updates are hung for several seconds for a similar > tracking table... > > http://archives.postgresql.org/pgsql-performance/2009-06/msg00300.php > > > > > > > > > > > > > another option is Pentaho, is good and easy too http://kettle.pentaho.org/
В списке pgsql-general по дате отправления: