×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 01-Mar-2015 13:44 -0600, Jon Paris wrote:
But you could surely waste a phenomenal; amount of disk storage that
way Chuck surely?
Not sure how to respond; minimally, I am not for sure what "that way"
means. I did not discount use of binary stream files, even while
suggesting possibilities to favor the use of rows of DataBase Files;
basically just sharing some thoughts on those two specific choices noted
in the questions raised by the OP about "storing them in the IFS"? or
"storing them in a SQL table?" and "why?".
In my estimation, a large number of images is going to take an amount
of storage that they must take [all that is required], irrespective the
image data being stored in objects of the IFS or being stored as BLOB
data within a DBF; 100K images of 50KB each are going to take ~5GB
regardless of those two means of storage.? While maintenance of the DBF
might result in /waste/ of some [even potentially a large] amount of
storage, the implementation of the storage requirements via the use of
STMF in the IFS is surely going to, upon reaching some very large number
of images, exceed the requirements for storage by the DB to accommodate
those same images; that is because each STMF object is implemented as
two objects, as well as the owning user profile must accommodate the
authority\ownership of each object. That additional ownership has been
described as one cause of a DR time increase [for the SAVSYS and\or
SAVSECDTA] that has been a topic discussed several times on this forum.
Obviously the storing of many images in one or several large STMF vs
each image in a separate STMF is beneficial for storage; both for the
IFS and the USRPRF. But personally, I would rather gain the advantage
from just using the existing DBF support rather than trying to define my
own imitation of an existing storage algorithm for which I might still
need to define routines to interface with the database and still not
afford the commitment control to ensure the integrity that comes /free/
with the DB.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
