Jump to content
  • Advertisement
Sign in to follow this  
Rydinare

Discussion: Overuse of Database?

This topic is 3493 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi guys. I ran into an interesting design decision at work, and I wanted to get some weigh in. I wanted to present two scenarios and see which you guys thought might be better: Our needs are a tool to monitor the status of our application. The tool that monitors the status would need to report on failures in our application. A) The tool to monitor status could send out an email to the designated recipient of issue reports. The only issue here is making sure the system is configured to allow email and that there's no firewall issues. B) Another suggestion was to simply write the information to the database and there can be a tool from the recipients side which periodically polls the database for any new issue reports. Personally, I have a problem with suggestion B, because it just seems like overuse of the database -- not to mention that the polling doesn't really scale well. Nonetheless, I wanted to get your thoughts, see which option you prefer, or if there's an option C that hasn't been discussed. Thanks. :)

Share this post


Link to post
Share on other sites
Advertisement
An option C might be to do both: have the tool send an email, as well as adding an entry to the database. This gives you the advantages of both as well as allowing querying, reporting and other useful features which the database provides. You may also be able to get the database to send the email itself via a stored procedure, depending on your database system.

Share this post


Link to post
Share on other sites
Well, if you did your monitoring tool correctly, then the response to the event is whatever you want. An email, a db insert, both, nothing...

In general, I know business would love a timelined uptime table in the db to get reports from.

Share this post


Link to post
Share on other sites
It all depends on your needs. Is this application used solely inside your organization, or are their copies being run by clients elsewhere in the world?

If it's restricted to your organization, and you have access to the machine that runs the app, and the application is running on Windows, you could write to the event log instead of a database.

Actually, if you are running on Windows, I would recommend writing errors to the event log first, before emailing them or sending them to a database, so you always have record of an error just in case network connectivity gets severed.


Share this post


Link to post
Share on other sites
This is a tool that won't be just internal.

I think from all you guys have said, I'm leaning towards a mixed approach. It sounds like email updates upon import events is useful, an audit trail for uptime in the DB for gathering statistics, and writing all errors to the event log are all useful.

Share this post


Link to post
Share on other sites
d00fus's options C is definitely what I would pick. Logging in a database is a good idea. Periodically checking doesn't really make sense therefore you should send an email as well.

-CProgrammer

Share this post


Link to post
Share on other sites
Why not use a plain normal oldstyle logfile? It's nowhere as much overhead as a database, and nowhere as problematic as sending out emails.
If you want a close to realtime "heartbeat" functionality, you need a different solution anyway. When your machine has crashed and is burning, it won't send emails anyway, nor would that help.
On the other hand, if you only need to review non-critical errors, a logfile works just fine. ssh yourhostname tail -f logfile may be the only "tool" required to read it, which is a plus.

I'm not a friend of sending emails automatically because such mechanisms can easily cause more havoc. Automatisms usually aren't very smart.
Think of those "blah error, an email has been sent to the administrator" websites. And now think of an angry customer coming across such an error page on your site. Let's just hope he never heard of ab or httperf, and let's hope he doesn't run one of these over night.
Or imagine opening your mailbox in the morning and getting 76,000 identical "warning, blah <some unimportant thing>" messages.

Much better to write all that to a logfile, and if you think you absolutely have to email it, then do it as "digest" once per day, or twice.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!