On the Howie side, maybe it's a good idea to include a little more
flexibility - so that you can tell iMS where store it - FILE or ODBC.
Using a FILE method would create the file, and return the name of the file.
the ODBC method, insert the record into any odbc database and return the
primary key. The one big difference, the ODBC method, the user should be
able to type the INSERT statement that iMS would use - this would give the
flexibility of working with any table/structure format. The other input
option would be the field returned for the primary key.
Next opinion. I recently did a huge financial reporting system, where there
are over 500,000 PDF documents stored as blobs in SQL 7. Although this
makes maintenance EXTREMELY easy, there are several disadvantages.
- CFQUERY won't return the value from a blob field in sql7, of course, there
are other ways to go about it.
- The database size gets very large, so it will hinder performance
The other problem I can see is what other people mention with quotes and
other characters. This generally wouldn't be a big issue, but there are so
many cases where it can pop-up and require some string escaping - so, in my
opinion, string escaping would be absolutely required, although not always
required (again, depending on what you are doing).
I also think for a large ISP, or whatever, if they had millions of e-mails,
that the performance would be better in a file format rather than in the SQL
db. Of course until a real benchmark is done (oh god, not here!), then it's
pure speculation. Not too mention, if you have a 1 meg attachment, I think
SELECTing that record will be slower than reading the file by itself, no to
mention there are numerous ODBC limitations you would have to get around
(ie: no using cfquery, but rather ADO as a cfobject).
Tom
----- Original Message -----
From: Adrian Cooper <[EMAIL PROTECTED]>
To: inFusion Support List <[EMAIL PROTECTED]>
Sent: Saturday, July 29, 2000 3:37 PM
Subject: Re: [iMS] SQL File Storage
>
>
>
> >
> > What is your setup in this case? I have yet to find a character I can't
>
> insert into a SQL Server 7 char/varchar/text field via ODBC and a simple
INSERT
> statement. I'm curious because a couple of people have mentioned this,
but I've
> never had such a problem with SS7 (Access, yes).
> >
> > Otherwise I generally agree that storing mail in flat files makes a lot
of
> sense for many reasons. >I can see how storing it all in the DB might be
useful
> in a specialized application though.
>
> Well yes - I agree there. For ISP, or large scale email provision clearly
out
> and out performance is the order of the day, and as users aren't paying
much, if
> anything, for the service, then all of the bells and whistles are just not
> appropriate generally speaking.
>
> If OTOH one is providing corporate email services, and the customer is
paying
> for a first rate mail service, then equally clearly SQL based message
storage
> opens up a whole new range of possibilities of considerable value to
corporate
> and other large organisations - services which would put iMS way ahead of
the
> rest if it could do that.
>
> Of course - equally important to corporate organisations would be Virus
scanning
> of all mail, including quarantining and user/recipient notification of
suspect
> mail pending further actions, and high level spam filtering - all these
things
> are almost essential in this day and age. We know of an excellent virus
scanner
> which beats most of the others hands down, is DLL based for performance,
and the
> manufacturer does not charge a per user license - so, for example, the
hooks
> could be integrated with iMS and/or FusionMail (and other WebMails for
iMS), and
> offered as a module.
>
> The product is Norman Defense Systems which used to be known as the
Thunderbyte
> Scanner - I used that years ago, and it was the best then even. See:
>
> http://www.norman.com
>
> Spam filtering is something which we can implement at template/SQL level,
and I
> have defined a possible schema for that already for "per user-user
managed" spam
> filters, which could be managed through a WebMail interface and switched
on/off
> and defined at will by the user.
>
> So it is horses for courses - but the more iMS can do, the better it will
be.
>
> Adrian Cooper.
>
>
>
> ========================================================================
> This list server is Powered by iMS
> 'The Swiss Army Knife of Mail Servers'
> --------------------------------------
> To leave this list please complete the form at
> http://www.CoolFusion.com/iMS.htm
>
> List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
> ========================================================================
========================================================================
This list server is Powered by iMS
'The Swiss Army Knife of Mail Servers'
--------------------------------------
To leave this list please complete the form at
http://www.CoolFusion.com/iMS.htm
List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
========================================================================
