I mentioned the performance problem because we currently have that set up in one of our sites. All inserts, updates, and deletes are logged to a table, and it is impacting our performance. We are currently in the process of moving away from that system but, for us, it's a bit of a challenge because we are in a clustered environment, and we want to ensure that the log is centralized between various database servers.
As far as managing the query log from within the backend, it shouldn't be too difficult to parse the log file. But if you want to go with the log-into-db route, take a look at Zend_Db_Profiler: http://framework.zend.com/manual/en/zend.db.profiler.html <http://framework.zend.com/manual/en/zend.db.profiler.html>You can build a late-running controller plugin that waits until the request has been fully dispatched before gathering all the inserts, updates, and deletes. Once you have all the data you want to insert, I suggest performing a bulk insert. -- Hector On Fri, Jan 22, 2010 at 9:02 AM, Guillaume ORIOL <[email protected]> wrote: > I know the potential impact on performance, Hector. > But I need only to store INSERT, UPDATE and DELETE queries, not SELECT > and as I stated, it is only for SOME tables. > > The solution you suggest is not ne right one for me as the result could not > be managed in my application back-office. > And this is what I am looking for. > > Writing to the database for every read can have a big impact on > performance. If you're using MySQL, I'd take a look at the built in query > logger, which writes queries to a file. > > http://dev.mysql.com/doc/refman/5.1/en/query-log.html > > -- > Hector > > > On Fri, Jan 22, 2010 at 7:29 AM, Guillaume ORIOL <[email protected]>wrote: > >> Hi, >> >> I would like to implement a query tracker in Zend_Db for some tables. >> The idea is to store in db an history of all SQL queries that were >> executed on these tables. >> >> Here is the kind of table schema I would like to populate with it: >> CREATE TABLE table_history ( >> id TIMESTAMP NOT NULL PRIMARY KEY, >> tablename CHAR(64), >> query VARCHAR(...) >> ); >> >> I was thinking of using db profiling mechanism to do it. What would you >> suggest? >> -- >> >> Guillaume ORIOL >> >> > > > -- > > Guillaume ORIOL > [email protected] > [image: Technema] > TECHNEMA > TÈl : 01 60 94 70 30 > Fax : 01 60 03 12 40 > Mob : 06 81 43 04 06 > >
<<logo_technema_136x100.jpg>>
