Hi David

I will take your word on it :)

In our case its more basic. An application used by many business
storing information about clients , creditors and stock. You could call
it 'Accounting software'. Every user has different data that needs to
be stored about these entities. We build as many as we can generically
do so. We then have some standard fields that can be named (for display
purposes) as anything. Past this, where users just need to store data
on a product (etc) we provide the ability to add your own data fields.
They are one to one, one item has one record of extra data. This data
is not used by the application, because it varies (or doesn't exist)
between clients. It is used for reporting purposes where the customer
has their own customised reports and can be used by any customised
software produced for them.

So in a nutshell it is just a way of storing extra, unforeseen data.
One example is a book store who stores, cover images, sound bytes,
except text and reviews of each book in the system.


im off for the weekend :)

Merry Christmas

Rob Martin
Software Engineer

phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com

Wild Software Ltd



David Johnson wrote:

>This happens a lot in metalogical business modeling frameworks. My shop
>produced one such product, and we are using two others that are produced
>by other companies. These are used for problems that are not amenable
>to traditional relational analysis and modeling tools.
>
>It's not so much "wily nilly" as an admission that the business that the
>application supports is subject to either frequent changes or heavy and
>intricate customization. The metalogical framework means that
>modifications to the production system typically will not require a
>programmer's skill set so much as a business person's skill set.
>
>A prime example is a contract monitoring engine for a company actively
>seeking new customers. Every contract is similar, but not sufficiently
>so to be amenable to in depth relational analysis in the classical IT
>sense of the word. Our data modeling team (aggregate experience of
>about 60 years) admitted one such problem was not relational after about
>a year of concentrated effort.
>
>You use this approach when the relational constructs you end up with are
>horrendous, but the metalogical constructs are simple and easy to pass
>on to a non-programmer.
>
>
>
>