Re: Old Debate, New Day - MVDB vs. Other DBs


dawn wrote:
Excalibur wrote:
"Mike Preece" <michael@xxxxxxxxxx> wrote in message
news:1152965939.352636.92310@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

<snip>

Suppose you have something like a dictionary - but for the entire
application, rather than just a single file. Each item has a unique
number - like an attribute number, but pointing to a "state attribute"
instead of (well - in addition to, actually) the attribute number in a
particular file.
Well I think that it is a great idea. I have been using a system dictionary
since 1977 and yes the same system variable is used in every screen that
needs it. By system I mean say Debtors (Accounts Receivable for some of
you) + Stock (Inventory) + Order Entry, or General ledger or Creditors
(Accounts payable) as opposed to Dawn's definition of the entire Pick
system.

I'd like a single metadata repository for the entire "namespace" with
CRUD services that perform the relevant integrity services. Then both
CRUD and UI components can make use of the same metadata for validation
and such.

As for the state operated version we did that in 1977 as well but I dropped
it a few years later. Originally it was a massive speed demon because of
re-entrant and recursive code however we moved to machines that ran
partitioned code for each user and that method was deadly. I also developed
a hatred of black box code as it is unmaintainable by anyone but the
original writer. Now I use the parameters to generate rock solid code that
can be debugged - it is much easier because you can ignore 90% of it - and
if we are not able to support it anyone can do so as all the code is there.
Plus it is clearly documented in parameters, the only code that the
developer adds is the business rules.

There is some complexity added when users can add and maintain business
rules or any other metadata, but one way or another ever application
permits users to specify such rules, perhaps only with flags and other
settings that don't look like a rules language. Then you need to make
a distinction between metadata that IS the system and could break
something if it changes and metadata that serves in "user exits" where
nothing structural breaks if it changes. Do you put both types of
metadata in the same repository?

Yes. This is why I used the word "application" rather than "system".
You only want to refer to "fields" that form part of the application -
rather than things like the spooler or MD or dictionaries or other
files that form part of the system or framework architecture. For more
background on what I was trying to describe you could google this group
for some source code I posted yonks ago. Look for "call
@postsub(infld,fld.mvno,add.inflds,outflds,suberr)".

Also - with reference to Peter's comments - I have some experience in
dealing with code-generators but have found that an architecture that
does it all according to parameter settings is vastly suprerior, for
myriad reasons. Not least of these is the minimal amount of "metadata"
and code that needs to form part of "release" when you issue an
upgrade. Also - you can keep up with revisions to things like w3c's
standards by simply adding new parameters, or attributes, to the
FieldDefinitions file to cater for any additional properties etc.. The
code I pasted a while ago has changed a bit over time. Not a lot, but a
bit. I used to have a bit of HTML which related to the presentation of
a field in a (multivalued) number of web pages in which the data was to
be displayed. Now that HTML has been replaced by property settings.
It's those settings I was refering to above. There have been other
changes as well, but the basic "kernel" for the framework is there in
that ASPick code for all with eyes to see.

As for the "What if someone does something stoopid?" questions... I
dunno. Keep backups? Charge 'em? It's up to you and the circumstances.

Mike.

Is the one an override for the other
so that the applications first check the user overrides (for that which
can be overridden) and then check the central repository?

By the way it is written in itself -
if it is that good you need to use it and if it breaks you are the first to
know not the client.

That's a good think. cheers! --dawn

Peter McMurray

.