有效地设计一个简单的邮件客户端

发布于 2024-07-16 08:33:34 字数 597 浏览 8 评论 0原文

要求: JAVA桌面邮件客户端可以连接到现有的gmail,y! 邮件a/c & 将允许接收/发送邮件,支持邮件的离线查看,以及更多功能 当谈到。 我正在使用 Java Mail Api 的

底层邮件存储:我决定将 HSQLDB休眠。 电子邮件内容可以有附件、HTML,所以我决定使用 LONGVARBINARY 类型来存储电子邮件正文和正文。

请让我知道这种方法是否好& 在检索方面它会给我带来良好的性能吗? 还给我一些关于如何将 HSQLDB 中的 java 电子邮件对象存储为 LONGVARBINARY 类型和类型的指示。 如何取消引用它以获取实际数据。 ??

2)我对此感到困惑,因为使用方法 1,我最终将以某种方式将所有邮件内容存储在本地磁盘上以启用离线查看。 想象一下,如果我有 1GB 的邮件 >

Requirement : JAVA desktop mail client which could connect to existing gmail,y! mail a/c & will allow receive/send mails, support offline view of mails, plus with more features as & when it comes. i am using Java Mail Api's

Underlying Mail Storage: I have decided to use HSQLDB with
Hibernate. Email content can have attachments , HTML , so i decided to use LONGVARBINARY type to store the email Body & attachments.

Please let me know whether this approach is good & will it give me good performance when it comes to retrieval. Also give me some pointers on how to store java email objects in HSQLDB into LONGVARBINARY type & how to dereference it to get the actual data. ??

2)I am confused over this because , with Approach 1 , i will end up storing all mail contents somehow on my local disk to enable offline viewing. And imagine if i have 1GB of mails >

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

烟雨凡馨 2024-07-23 08:33:34

如果您使用基于文件的方法(这并不排除您使用数据库),您可以在不使用时压缩和解压缩用于持久性的文件。 由于您将存储简单的文本,因此压缩可能会很大,并且如果您在明智地选择的时间进行压缩,速度下降也不会那么糟糕。 天啊,你甚至可以把它作为一个选择。

(对我来说)这里要考虑的最重要的事情是搜索时间。 您希望用户能够搜索什么? 如果搜索很重要,我可能会使用数据库。 我解决该问题的最初方法是将主题和标题信息(日期、发件人、收件人等)存储在单独的列中,然后将整个电子邮件对象序列化为二进制数据列(可能已压缩)。 这会使全文搜索花费更长的时间,但无论如何这是可以预料的,对吧?

If you use a file-based approach (and this doesn't exclude you from using a database), you could compress and decompress the file(s) you use for persistence when not in use. Since you will be storing simple text, the compression is likely to be significant and the speed decrease would not be all that bad if you do it at intelligently chosen times. Hell, you could even make it an option.

The biggest thing (for me) to consider here is search time. What will you want the users to be able to search? If searching is important, I would probably use a database. My initial approach to the problem would be to store the subject and header information (dates, sender, recipient, etc) in separate columns, and then serialize the entire email object into a binary data column (possibly compressed). This would make full-text searches take longer, but that's to be expected anyway, right?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文