I agree Joe. That does raise some interesting questions. Off the top of my
head (pointy as it is...), I would think you probably would not want to save
LOB data on a regular basis anyway as it probably is not as volatile as
normalized data. How often does an image change anyway? I could see
setting up change-object-date rules on it to save it as needed, but
otherwise, only save it on a once a month (or more often if necessary for
business requirements) basis.
But that's just off the top of my head. This requires tons more
consideration than that.
This topic has really twixed the synapses of my brain today for some reason.
Very interesting!
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Monday, May 14, 2007 12:31 PM
To: 'Midrange Systems Technical Discussion'
Subject: Saving and restoring LOB data
(forwarded from a discussion about the maximum length of VARYING fields in
RPG400-L)
From: Buck
Isn't this what a Datalink field does for you? The concern with
datalinks,
though, is that they aren't saved and restored with the SQL data.
Exactly, and so now we step straight into RPG's strong/weak point -- the
tight integration with DB2 for i5 OS. Without that tight integration,
RPG is just a funky scripting language for SQL. With it, the compiler
folks need the database folks to er, cooperate :-)
This is an interesting issue. Ignoring your little slam of RPG (without the
engine, a Ferrari would just be a funky soap-box derby car <smirk>), the
whole issue of LOB archival is a good one.
As more large objects become a requisite part of data management, should
they really be part of the standard save/restore of relational data? It's
an interesting question. While the initial reaction might be that all
related data should be saved at the same time, it seems that the very nature
of much LOB data (large, essentially immutable streams) means that the very
archival medium (much less things like retention rules) should perhaps be
different for this sort of data.
So should we now start thinking about multi-medium save and restore
capabilities? Specifically relating back to SQL, should we in effect be
able to assign different save/restore attributes at the column level?
It's an interesting question, and one we already face to a smaller degree
with basic source management. Now that things like HTML files and images
are part of our application architecture, the standard QSYS source member
save and restore no longer works. And simply bumping up to a Unix-based
source control system doesn't work, since we're not just talking about
multiple data types, we're talking about multiple platforms! There aren't a
lot of complete multi-tiered version control, build and deploy solutions.
Ah, the new world of computing.
Joe
midrange.com
