Hi J,
I also agree your position on this, to test and trial the software you want to be able to create classes, attributes and subsequent relationships, enter data, determine how that appears to the user and modify as necessary.
I also found this concept of getting it right first time difficult, so what I did was created both a test, template and live instance of CMDBuild. Test is simply snapshotted live data but before I started entering data I used it to play around with and trial how users would see the classes, Administrative interface is now filled with stuff but only in test.
From there I spent around a week designing 5 core super-classes to build my data model on, but it was designed in a way that I could add and remove superclasses+sub-classes and treat them as 'modules'.
This meant I had a flexible hierarchy of classes and built an ER diagram from my Class diagram but tested everything in my test instance, snapshotted the data model after it was created in CMDB and put it in my template system and then rolled it all out to live.
Now when I want to change the data model for classes with data (which is rare anyway), I make the changes in test, approve the changes to the data model and update the base template then roll it out to live.
I rarely have to delete an attribute but when I do, I disable it for the users and go through a cleaning phase every quarter where I purge the data and attribute on the database using SQL assuming it's no longer required.
So to make the CMDBuild software pay dividends, you really have to put a lot of thought into your data model. I spent around 2 months commissioning our CMDB, putting together a change process for data model changes and had numerous people review and approve my data model.
If you want an easy route but with a much lower level of customization, try looking for a CMDB product which already comes with a data model.
Thanks,
Jamie
Previously J wrote:
I just responded to an old thread but realized it was for a specific scenario - I'm starting a new thread to understand how this system works with respect to design changes.
I'm just starting to use the program and am attempting to build a few classes into the system, link them and see how they all related - quite immediately I've come across a "limitation" (?) in so far as you really cannot delete anything once records (cards) have been saved... as the database holds versioning data it will always tell me that the table contains data.
My question is - how do I manage design changes where I might want to delete an attribute - a class - or a domain relationship? I realize I can mark things inactive, but that means my administrative interface will become full of junk and be very difficult to administer over time. I know I could access the DB tables directly, but I don't want to imagine what kind of mess that could create by deleting the things improperly.
Is there anyway to overcome this? Have I missed a delete function somewhere?
Any help is appreciated - this really looks like a great product, but it seems to require the designer to get it right the first time.