Reply to post: Reinventing triggers?

Google drinks from Oracle's pond: SQL system log slurp part of grand data-sharing vision

Charlie Clark Silver badge

Reinventing triggers?

While I can think that this kind of thing might occasionally be useful I do worry about going outside the existing toolchain to do so, certainly when it comes to replication. If you need to replicate the DB, you'll presumably have the setup and the tools, this approach seems to depend upon inferring changes from the log. Where's the guarantee that things work? Any change to the log file format or junk could cause all kinds of problems and leave you in no mans land.

Similarly, you might want to kick off some analysis in certain conditions but DBs already come with the tools to do this. I assume the idea is that you can use this approach to "scale" up when necessary so the precious on site resources don't suffer from a rogue CPU hammer of a query. But anything that offloads data processing to another environment needs to get the data there and network latency is usually a bigger problem that CPU load, especially if this enough data to warrant processing elsewhere.

But maybe the examples just aren't detailed enough?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon