×
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 28-Feb-2015 10:21 -0600, RPG List wrote:
<<SNIP>> I'd like some feed back from anyone willing to contribute
on how you store your HTML images for use on the iSeries.
ie. are you storing them in the IFS only, are you storing them in a
SQL table? If you don't mind, I'd like to know why your storing them
as you do as well, what the reasons were for the choice you made.
I know some websites in general store them (especially those which
are PHP table driven) in a database like MySQL or MS SQL server,
etc.
On the IBM i as an object-based system, there is necessarily an
overhead associated with storing distinct items of data in separate
objects, as contrasted with storing the distinct items of data as
separate values within rows of a database; not to imply that the data
items would not also, by implementation, be stored as objects, but the
data items would be /simpler/ for not requiring all that is needed to be
tracked and exposed as separate objects. For example, past
conversations here have noted how, as the number of IFS objects grows,
the impetus to move the data into a database file grows due to the
impact on backups [and probably also recovery] for a /large number/ of
IFS objects.
Given most images have a correlation with other row-data, and given
the likely difficulties of ensuring data integrity\consistency [e.g.
with DataLinks support] across multiple storage locations [IFS for
images and DataBase Files for the row-data] versus just one storage
location [such as in just a DBF], the choice to combine the images into
the existing row-data model may have value. The accesses of both images
and the other row-data is consistent; e.g. the coding for storing,
updates, and accesses are all via the SQL rather than some being via the
IFS and others via the database [SQL]. Additionally, the use of
commitment control for atomicity of the actions on the images as
row-data alone, is quite simple by comparison to trying to achieve that
atomic effect of operations when the storage of an entity is spread
across the DB and the IFS; part of achieving the integrity\consistency
alluded above.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.