I'm using OpenPop.NET to retrieve emails from client. My idea is to have a service that's working on the background to keep storing new recieved mail from time to time instead of geting it from the client when the user tries to check it, because: performance.
So my question here is: is it a better idea to store the emails info to the database or save it to file as in the OpenPop example
I was thinking the better would be a database solution, because Message-ID is not unique this way i could open email details using my own IDMessage. But this is my first time working with recieving emails and am not sure if there's any motive that i shouldn't do it this way. So i'm open to opinions and advices.
Related
I need to log the last time the user signed in using my node.js server. I am looking into three options. The persistence requirement is not super high, meaning that the margin of error of this record being recorded is open.
Use SQL DB and whenever the user logs in it modifies their profile account.
Record it in a server text file. So whenever the user logs on, this file will be opened and updated. The opening, recording and closing of the file will all be done asynchronously.
I'm thinking that the second option is the better on because I'm using SQL for many other operations so I prefer to not interrupting my DB as much as possible.
One concern I have for the second option is the performance hit on the server that will be caused by the frequently read and write to a local text file.
I'm curious what other people who have gone through this path thought about my thought process. Any opinions or tips are highly welcomed. Thank you.
Normally you should use a SQL database, it is a much more better way than the plain text.
The main problem with a text file is that when you log in, you can simply append a line (but what about a couple of user loggin in at the same moment ? You have not any warranty that all the access are logged), but when you want to extact the last login for a user, you should read (and then load) all the file from the start (or the end), which can cause a really worst problem than the access to the DB.
Naturally you can work out all the problems with a text file, but then you have written a lot of code to avoid a simple update query.
I don't think that, with the information you give, you should be worried about the performance of a database access in this case.
When we enter our credentials, the mail box opens which is sent from the server. But we are able to manipulate it like deleting messages, or moving messages from one folder to another.
And next time we re-login it is in the same status, although the page again came from the server.
It means that the changes we made were saved on the server.
Then why do we say that we can't make changes to dynamic web-pages sent by the server to the client ?
I'm not sure if I understood your question right.
When you move E-Mails in another folder or do something else on the website, your changes will take effect on the server not on your client. So you don't really change the dynamic web-page, you change content properties on the server. For example a Message could have an ID and then theres a Table which will Map Messages by Id to Folders. When you move a Message to another Folder, Database Entries on the server will be updated.
I am in the process of migrating from a recruitment ATS called Bullhorn, who also acted as our mail server. We have been provided with a backup of our data which includes all our emails stored in a table - so far so good. However, each of those emails' bodies is stored in the database table as an Image type as a zipped binary (Not so helpful).
I'm pretty stumped with how to get this stuff out. There is a forum in which there is a thread dedicated to this but predictably Bullhorn are not so enthusiastic spending time supporting customers who are migrating away. Here is the thread: http://supportforums.bullhorn.com/viewtopic.php?f=34&t=1672
As I explain in that thread, I have used a program called Chilkat with which I can successfully read a table row, decompress the Email Body Column and display the raw HTML in the console window. But now, I don't really know where to go. I've read in to Datasets and Table Adapters but I'm not too sure how I can get the Chilkat software to work on data within that dataset.
So, I wonder if anyone can help out with this and provide some guidance?
Or.... I've been reading about using SQL to store binaries and it seems it has it's own compression - so could I use a CLR as a stored procedure to be able to give better access to this data.
Ultimately, I'd like to be able to output this in to either a CSV file or use GeniusConnect to recreate an Outlook file - ultimately ending up in Gmail.
Any help will be greatly appreciated.
(Originally posted not being logged in - added this to stop it being flagged as a duplicate)
Thanks!
Chris
I have to make an app that wants to be able to modify some mail content items from an email server that is implemented with Microsoft Exchange Server.
On the PST files approach I'm ok as I know how to deal with this.
The problem is I don't know how does Microsoft Exchange Server dealing with mail content and PST files. As far as I know PST files are only a way to backing up mail content and structure, something like an sql dump file. I heard that Microsoft Exchange Server would internally actually use a SQL database for storing these content items. As I need to make permanent modifications to email content from client perspective I need to know the following:
- How does Microsoft Exchange Server stores it's mailbox content items? By database or PST or both? If both, how does he do the syncing ? (in here I am partially referring to the concept called "CachedExchangeMode")
- How is the data flow on the server perspective in the content of Microsoft Exchange Server ?
- How can I communicate with the Microsoft Exchange Server as a client for content manipulation ?
Any info about this topics are welcome, as I'm stuck in finding any documentations on these.
Thanks in advance guys !
Thanks Dmitry ! I need to develop a solution that makes sure permanently deleted mailbox items can't be restored by dedicated server or client tools (like scanpst for the client host, which works on PST files). On the client perspective I managed to get a close solution on modifying the PST files so that by wiping the free memory blocks the files won't get corrupted and those informations would be really lost. But on the server side, mainly on the Exchange Server side (because Exchange is somehow more special than otehr servers) I don't have any data on how to make this data really lost. I must mention I'm starting with the hypothesis that I have access on the server host from the server host and from client too. From my hunch Exchange could store it's mailbox items on the database but they would permanently delete those items only by logical flags in the respective records. Or they can make use of a PST server file that has the ability to store the permanently deleted items just like Windows's recycle bin, providing the means to recover some of the deleted items (in this case the database could really delete those records as the recovery method should lie in the PST file construct). Maybe Exchange uses both methods. In all cases, I need to make a solution that provides 100% confirmation that those items are really lost. This is why I need specific documentation or confirmed "hunches". Did I described more clearly the context of my question Dmitry? Thanks !
I now had read some info related to the way Exchange manages it's mailbox items deletion. It moves the soft-deleted items to the Dumpster platform on each deletion stage (firstly into the "Deletions" folder, and then intro the "Purges" folder, and on litigation hold activated, it additionally preserves original mailbox messages to the "Versions" folder). I then found a way to use the Exchange Power Shell to delete those items, and even read about the Remote Power Shell way to programatically acess the Exchange Power Shell to do this programatically. THis is as far as I gone. Would this be a solution for what I have to do ? Would this assure those items aren't recoverable by any means ? Do you know another solution for this or is there something I am missing ?
Exchange stores the data in its internal data base. It format is not documented.
On the client side (cached mode) the data is stored in an OST file (you can think of it as a glorified PST file). Outlook periodically syncs the OST data with the online version of the mailbox.
What are you trying to do? From the client point of view, if your code works with a PST store, it should work just fine with an Exchange store, either cached or online.
Can you be more specific?
If you have a site which sends out emails to the customer, and you want to save a copy of the mail, what is an effective strategy?
If you save it to a table in your database (e.g. create a table called Mail), it gets very large very quickly.
Some strategies I've seen are:
Save it to the file system
Run a scheduled task to clear old entries from the database - but then you wind up not having a copy;
Create a separate table for each time frame (one each year, or one each month)
What strategies have you used?
I don't agree that gmail is an effective backup for business data.
Why trust your business information to a provider who makes no guarantees of service, or over who you have no control whatsoever?
Makes no sense to me.
Depending on how frequently you need to access this information, I'd say go with the filesystem or database archive. At least that way, you have control over your own data.
Data you want to save is saved in a database. The only exception that is justified is large binary data (images, videos). Who cares how large the table gets? If the mails are automated and template-based, you just have to save the variable parts anyway. The size will be about the same wherever you save it, but you probably already have a mechanism to backup your database, so you won't have to invent one to handle millions of files.
Lots of assumptions:
1. You're running windows / would like an archive in windows
2. The ability to search in the mails is important.
Since you are sending mails to your customers there isn't any reason you can't bcc a mail account of your own. Assuming you have a suitable account on your own server then I'd look at using MailStore (home) to pull the mails out from your account and put them into it's own compressed database.
Another option (depending on the email content) is to not save the email, but make sure you can recreate the email by archiving the original content that went into generating the email.
It depends on the content of your email. If it contains large images. I would plump for the file system. Otherwise if your Mail table table is getting very large very quickly I would go for the separate table, archiving off dead customers.
We save the email to a database table. It really doesn't get that big that quickly. We've a table with 32,000 emails in it (they're biggish emails too # 50kb per email) and with compression, the file only uses 16MB.
If you're sending a shed load of email, then know that GMail(free) currently only allows 7GB of data. I'd be happy holding that on a disk.
I'd think about putting in place some sort of general archiving functionality. How you implement that depends on your specific retrieval needs.
For example if you wish just to retrieve emails sent to a particular customer for a certain month then stocking them in an appropriate heirachy on the File System (zip them up if necessary) should be simple to do. You might want to record a list of sent emails in a database table with a pointer to the appropriate directory but a naming convention for your directories and files might be sufficient
You might not need to access very old emails very infrequently so you might archive these to DVD for example if online storage is a problem
If you're wanting to often search the actual content of emails then your going to have to put the content in a DB table or use an indexer like Lucerne to examine the files stocked on disk