Conference azur::mcc

	The current  thought  is  that  we  don't  want "users" mucking
	around directly with  data  we  will  be  storing  in  the  MIR
	database.   We are  currently  planning  on  having  an  export
	function on Ultrix to move  user requested data from the MIR to
	an SQL database where they can  then do whatever they wish with
	that data.

	The plans *may* change over time, but  for  now  you  know what
	we're thinking...


	JCE

    You still have to export. (Although it can be into the same database).
    Problem is that we don't know a-priori the data structure of what is
    going to be stored.  We would have to create a separate table for each
    possible combination of class and selected attribute set, we would then
    need to do 100% dynamic SQL access, looking at the metadata for each
    table before constructing queries/stores against it.
    
    So in V1.0 MCC/Ultrix, the data is still stored in generic MIR format
    (ILV encoded with flattened entity hierarchy).
    
    What we need to do in the future is compromise a bit and provide some
    setup function where the MCC user tells us what classes/attributes
    he/she intends to store in the MIR and setup application-specific
    tables at that time.
    
    

    Jim, thanks for defending the MCC db schema, but I wonder what other
    products do about this?  Merlin, for example.  If I'm not mistaken,
    Bruce Kelley told me that Merlin explicitly describes to the relational
    DBMS what the attributes of the entity class are.  I don't know the
    details of how they do this, but Merlin also claims to be extensible -
    to allow new SNMP attributes to be added on the fly.  If they can do
    it, perhaps there is some easier way to do it (that I was not aware
    of), or maybe MCC can learn it from them 
    
    It seemed that there would be 2+N relations, one for the entity
    instance data, one for the relationship data (never got done), and N
    per-entity-class relations, with all of the entity class's  attributes
    appearing as attributes of the relation.  It seemed pretty
    straightforward to generate an SQL script from the dictionary that
    would get you started.  Queries could be difficult, but it seems
    possible that most of that logic would be buried in the MCC_DB
    routines. Also, you could start to take advantage of other programs to
    do the querying, such as RALLY and TEAMDATA. Also, the hope was that
    the dictionary would be stored in the same way (or with CDD+, or...),
    giving us some "distributed database" capabilities.
    
    ben
    

    
    
    
    
    There are enough issues in the relationship between MC and its database
    to spend a lifetime with...
    
    I certainly did study the MSU database,  I wish life was as simple for
    us.   They hardwire all the SQL metadata at installation time including
    all tables and fields they need.   It's not generated off their
    dictionary - if you want to add an attribute, you have to go into SQL
    and a a column to the table.   MSU supports relatively few classes - so
    they've taken the option of exposing the structure to the user and let
    him extend it.   On MCC you're going to have at least one table per
    unique combination of class + partition - this could be a large number
    (not to mention that some of our partitions (DECnet) have more than 100
    attributes).    Do we generate all this metadata at installation time?
    No way - probably the first time we try to store it, but we're still
    going to have a tough time relating SQL table and column names and
    datatypes to the user's original MSL - if we can't do this clearly and
    unambiguously, there's no point in exposing the database schema.
    
    Also, as much as I've come to hate ILV encoding I must admit that it
    sure saves on disk space - the current version of ingres supports only
    fixed length records - null fields still take up space.  This is
    another issue to deal with.
    
    If we can answer some of the above questions, we can think about direct
    table/column storage of attribute data in the future.
    
    With instance data, things are even foggier.  MCC's data model is
    an arbitrary tree.  MSU's is a bunch of specific trees - for each one
    they've designed a set of tables specific to that class which represent
    any necessary hierarchy or repeating groups in the objects they deal
    with.
    
    Hierarchies do not map onto relational databases particularly well. We
    store each entity level as a separate record - to find A.B.C you have
    to find A, then find a B with A as its parent, then find a C with B as
    its parent.  Now consider that the identifier datatype for each level
    is some random selection from the 40 or so datatypes MCC supports. 
    (Ingres supports 5!)  And is not necessarily the same datatype even
    from instance to instance of a given class since we support alternate
    identifiers.   How can we store this in a relational-friendly way so
    that users can access it directly?
    
    Don't get me wrong.  I don't like obscure private schemas because as
    you pointed out, it takes away a lot of the benefits of using a
    standard database.  And I'm also not opposed to trading away *some*
    of our generality to make this work - but we have to do better than
    installation time hardwired SQL scripts.

    You're right about the difficulties that are faced here.   It's
    easy to create relations, hard to implement the general case of
    extensible managed object relational DBMS. Why I just dare you to put
    a Towerset into RDB! It seems to me that the basic problem here is that
    the relational DBMS has a very different information model than MCC,
    and consequently more s/w is needed to translate between the two
    information models.  Hopefully the object-oriented databases that are
    emerging now will be a better fit. 
    
    I'm not disputing that the decision was correct in the past, only
    suggesting that at some point you'll need a  more "open" database
    schema in order to increase acceptance with customers.   For example,
    accounting applications are probably going to want to drive off of a
    SQL DBMS.  Perhaps the use of SQL on the ULTRIX platform is a good
    stepping stone to the final destination :-> Perhaps an independent
    effort could be  made to generate SQL scripts from the dictionary so
    that MCC could "auto-export"...  Remember that 90% of the attributes
    use 10% of the data types, so plenty of useful data could be made
    available this way. I would have done it myself, but I'm too busy
    maintaining, you guessed it, NCL.  Put me out of my misery, please!
    
    ben
    

>    maintaining, you guessed it, NCL.  Put me out of my misery, please!

How about a job maintaining FCL instead?