Number of (Sub) Models?

[t_s]

I need to create a project that will have at least 400 'models' (actually sub-models of a top-level model) and the number and/or complexity of each will grow. Does EA have any sort of 'maximum' number of models a project can support? Or will is be just an issue of performance? I assume performance will be impacted by the particular deployment scenario employed.

[Geert Bellekens]

I suspect you might run into trouble as soon as you go over 32.000 subnodes of a single node as EA sometimes uses a short as the index.

I still think is a bad idea though. Usually when you have to ask about the limits of something then you are doing something wrong.

Geert

[Eve]

I suspect you might run into trouble as soon as you go over 32.000 subnodes of a single node as EA sometimes uses a short as the index.

I think that only applies to the API. Of course 32k elements in a package will cause performance degradation, but not as much as the time you'll spend looking for things.

[Paolo F Cantoni]

I suspect you might run into trouble as soon as you go over 32.000 subnodes of a single node as EA sometimes uses a short as the index.

I think that only applies to the API. Of course 32k elements in a package will cause performance degradation, but not as much as the time you'll spend looking for things.

Simon is absolutely correct.  We have developed some structures to handle alphabetised folders (and even two-level alphabetized - when the first letter isn't selective enough).

Paolo

[Uffe]

Hi t_s,

There's no meaningful limit to the amount of content in an EA project. What's been discussed above in this thread is putting 32,000 elements within a single package, which would be just silly.

As you suggest, it does depend on which database engine you choose, but even the old MS Access / JET can handle tens of thousands of elements in a project without difficulty.

For any sort of production use, I always recommend setting up a proper database of whichever flavour your company prefers. At the moment I'm working in a SQL Server repository with 4,000 diagrams, 3,000 packages and 57,000 elements, with no noticeable performance degradation for everyday use. Just make sure to select lazy load when you set up your connection.

/Uffe

[t_s]

Thank you all for your responses and answers.

As to the number of models in the project, this is a client need/requirement. The intended domain (of application) has 'true' enterprise scale (i.e., very BIG). The need is to be able coordinate solution architectures and have an overall integrated architecture. The multiple models will be solution architectures (each which I would expect, but don't know at this point, to have fewer than 32K nodes) that must be consistent with, and extend, the enterprise architecture.

[Geert Bellekens]

In that case I wouldn't worry too much.
Because of the design decision to store the model in a database it scales very well, just make sure to use a proper database.
For some reason (I don't know why exactly) I've heard complaints about Oracle with regards to performance from several different clients.
I've heard the best things from MySQL and SQL Server


Geert