× 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 Sun, 2015-03-01 at 14:44 -0500, Jon Paris wrote:
But you could surely waste a phenomenal; amount of disk storage that way Chuck surely?

Would there be much difference in disk storage between a set of
15K,120K,500K, jpegs on the IFS and a set of 15K,120K,500K jpegs in a
varying length blob field?

It should be noted I have no experience of blob, or similar large
unstructured variable length, fields so am genuinely curious.

OT: ... but from a purely abstract "if I designed databases" train of
thought, there is no reason the on disk structure needs to match the
presented data of a database. If a user designed a program that stored
pictures on the IFS and links to them in a table column, there is no
reason the DB could not do something similar "behind the scenes" an
invisible link within the DB row to an invisible "folder" with the
object linked.

I guess if you broke, or extended the sql standards on a single box
system you could also do something fancy like marking a field in the DB
as a "link type" then the IFS would know, or keep track of, which files
had DB reference links... then if a file was moved/deleted on the IFS
the change could be backtracked into the DB "link field" in a sort of
hard/soft link or you could work it like a true hard link, where only
when the IFS and all database "link types" were deleted or removed did
the file finally disappear.



Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Mar 1, 2015, at 1:53 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.