On Mon, Mar 2, 2015 at 9:16 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:
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.
I have found your responses illuminating because they are very
IBM-midrange-centric. Which is a good thing; I mean, we're talking
about IBM midrange.
As a nonnative midranger, I like to think of the IFS as basically
equivalent to the file systems on other platforms. And on some levels
it is, enough that I often forget the i-specific details (if I ever
knew them in the first place).
The typical thing to do on other platforms is to store images as
individual files in the native file system (analogous to stream files
in the IFS for midrangers), and I believe that is what feels natural
or intuitive to most folks using those platforms. Here's a nice Stack
Overflow thread, with information on why this is the usual practice,
as well as a few responses which remind readers to keep in mind that
what actually *works best* will depend on several factors, including
the nature of the file system and the database being used:
http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay
In light of the points Chuck has brought up, my thoughts are (1) IBM i
is probably a platform where storing images in the database is at
least as advantageous as the alternatives, (2) if you specifically
want to learn "how everyone else does it" then I would recommend the
stream file approach, because it's more common, and (3) most
importantly, you'll learn something worthwhile whichever approach you
choose.
John Y.
midrange.com
