I'm in the process of designing FileNet architecture for a large deployment.
There will be around 400 types of documents.
I'm in disagreement with my colleague, who says that the hierarchical, object-oriented structure is not necessary and we can create a single document class that will have a "DocumentType" attribute, which we'll use for type distinction instead of built-in classes.
His arguments are:
- regardless of class hierarchy, all documents end up in the same, DocVersion rdbms table, so there's no size benefit if you use class hierarchy (1 property template = 1 table column)
- the whole security is going to be handled outside FileNet
- other client's systems all have a single class so the integration is easier
- programming through P8 Java API is easier since you don't have to deal with 400 classes
My arguments are:
- easier to maintain FileNet system by adding new classes in inheritance tree
- it's not possible to define different property values in different classes: default, min, max, choice list, hidden (image bellow)
- if I split the data on two object stores for performance reasons, I'll need to have all possible attributes in each DocVersion table, so I could possibly hit database row size limit (btw, it's DB2, so for tablespace with 32K page size, row-size limit is 32677 bytes) in the future, as the client adds more property templates
- that's the FileNet way and I've never came across any other approach in all the literature I red (which is a rather poor argument by itself)
- it's not logical (which is also a rather poor argument by itself)
- imagine writing OOP programs this way, what a nightmare that would've been (how exactly this argument maps to FileNet?)
Why is this the FileNet way?
What are my other arguments?
Which problems could arise that I cannot think of right now?