SoftTree Technologies SoftTree Technologies
Technical Support Forums
RegisterSearchFAQMemberlistUsergroupsLog in
[SA 9.0.176 Pro] - FR: Views for model

 
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant View previous topic
View next topic
[SA 9.0.176 Pro] - FR: Views for model
Author Message
gemisigo



Joined: 11 Mar 2010
Posts: 1397

Post [SA 9.0.176 Pro] - FR: Views for model Reply with quote
When trying to import more than 50 objects into the model, Database Modeling starts complaining about them:
Quote:

You have selected 50 or more tables to import to the model and the associated Entity Relationships diagram. With that many tables the diagram will be difficult to read and navigate. It is recommended that you break up your model into logical groupings that are sufficiently small to diagram.

Click Ok to ignore this warning and continue or click Cancel to change the selection


I think it's pretty common to have vastly larger number of tables than that meager 50 (not to mention other objects such as procedures), even in a relatively small project. What's true, though, that showing them all at once will not work. I'm not sure what the dialog means under "break your model into logical groupings that are sufficiently small" but if you mean that the model should contain less than 50 tables, thus having multiple models for a single database, that probably won't work either. The border between logical groups in not that sharp most of the times and even if it is, those tables usually tend to be members of multiple groups at the same time. In my opinion, it would be much better to store each table (object) in a single model and break down logical groupings in that model, which could be achieved by defining multiple views that only show a few tables at a time, regarding their respective logical group definition.

DbSchema is a very good example how this can be done well (they call those views Layout). Except that it's a java app, to which I have an inexplicable born-with disdain for. And it doesn't play together with SA. Other than these, they've got quite a few exceptional ideas worth 'stealing'.
Thu Nov 10, 2016 5:52 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 6502

Post Reply with quote
Thank you for the suggestions.

Quote:
I'm not sure what the dialog means under "break your model into logical groupings that are sufficiently small"

That is a suggestion to create separate diagrams for different lines of business or different business functions, for example, separate diagrams for purchasing, sales, human resources, inventory controls, warehouse operations, security and entitlements, etc... You can of course have "shared" parts in all of them if you need them, or maybe a separate model for the shared objects. That 50 objects suggestion is just a suggestion, you can have more than that, it's not a requirement.


IMHO, separate files or separate layouts are the same thing. I think what makes a real difference in modeling is using of friendly descriptive names for models, and layouts, similar to how documents are named, and not using Model1, Model2, and similar non-descriptive names. Having very large number of objects in the same model file isn't good for a number of reasons, including large memory and resource requirements.
Fri Nov 11, 2016 2:40 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 1397

Post Reply with quote
SysOp wrote:

That is a suggestion to create separate diagrams for different lines of business or different business functions, for example, separate diagrams for purchasing, sales, human resources, inventory controls, warehouse operations, security and entitlements, etc...

I was getting the concept of breaking the model into logical groups. What was not clear was the "sufficiently small" and if that separation meant separate models.

SysOp wrote:

IMHO, separate files or separate layouts are the same thing.

Most certainly not.
SysOp wrote:

I think what makes a real difference in modeling is using of friendly descriptive names for models, and layouts, similar to how documents are named, and not using Model1, Model2, and similar non-descriptive names. Having very large number of objects in the same model file isn't good for a number of reasons, including large memory and resource requirements.


Nope. And I'm saying that with years of bad experience having (inheriting would be a better word) to handle and fix badly designed databases, models, and complete systems. Putting things in separate files here (from what I've witnessed, there's no inter-file connection between objects) is the same as putting related objects into different databases. Having properly named objects (while being indispensable) will not create, maintain, and enforce connections. Just as there's no cross database foreign key, it similarly breaks cohesion immediately, objects that are part of multiple models (layouts) will tend to get out of sync almost on their own and no amount of time and care will be enough to maintain a minimal level of integrity. Sure, it could be done, just the way you can impose data integrity across databases with triggers instead of foreign keys, you could sync objects back and forth between the different model files through the database (provided it is accessible), but like trigger solution, this also comes with overhead and strings attached. In the end it is such a vast waste of resources that simply isn't worth it. I don't think that would work with object number even approaching 50, and it will fail miserably when you get into hundreds, not to mention thousands.

Large memory footprint is not a factor to consider when modeling. Human resource spent to sync models manually is. Having to fix errors committed during the process is as well. I'm sure even low-end machines sport enough memory nowadays to handle thousands of object (not in a diagram, that would be dumb, of course, but in a collection).

Do not misunderstand me, I'm not talking about putting everything in a single file. I'm talking about handling everything that goes together in a single, coherent model. Doing it in any other way is not doing it right and is a straight road leading to failure I've already seen too many times.
Fri Nov 11, 2016 4:46 am View user's profile Send private message
Display posts from previous:    
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant All times are GMT - 4 Hours
Page 1 of 1

 
Jump to: 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

 

Powered by phpBB © 2001, 2005 phpBB Group
Design by Freestyle XL / Flowers Online.