I prefer it when the lines don't cross. This graph has other users who have developed their own unique logic for positioning table occurrences and it creates this weird mess.
1 Like
This is a total nightmare ! How much time to load it ? It's unbelievable that FMP can draw it.
Is is from a file you need to work on ?
I'm working on it daily. It takes a second or two to load and draw.
There is a positive: While I'm waiting for the screen to draw I can start typing the name of the table occurrence that I want to look at. When it draws the graph it is displaying that section of the screen with the table occurrence highlighted.
I guess I am just not thinking big enough. I can't even imagine why you would need so many table occurrences. I wish you luck in your endeavors.
1 Like
The system has been active use for more than 20 years. It has grown and grown.
1 Like
You may benefit from a search field there...
2 Likes
old product idea related to this topic:
https://community.claris.com/en/s/idea/0870H000000kALVQA2/detail
2 Likes
This looks like a literal application of the "spider web graph" technique... A bit too literal to my liking. Be sure not to delete the table occurrence in the middle...
I'm ok with some lines crossing, but I would be likely to change this setup, or avoid it altogether by taking most of my new work in a business logic file where things would be done in a transactional fashion and require fewer occurrences.
Good luck promoting a different "vision" in this file as it is.
This system grew from fmp6 days when it was one file per table. There are dozens of files connected to it.
Any change in a system as complex as this has to be carefully considered. I’m going to learn my way around before I offer any suggestions. Especially suggestions that are basically “interior decorating”
I agree with those points, and you are in the best seat to be the judge of that.
That said, I would take notes on the side of the suggestions you may have, even for "interior decorating." When we onboard a new company and a new system, our eyes have an authentic fresh look about things, the good and the bad, and some of that can fade away over time, depriving the organization from valuable feedback.
Also, there are some things that end up being less cosmetic than we think:
If I go to a house where someone has issues with hoarding or never cleaning up, to the point where I'm afraid of walking from the kitchen to the living room because I may accidentally knock the pile where 17 years of newspapers are stacked up and end up buried under it, I don't consider this interior decoration.
This image is simply to say that even if I'm sure a system of this scale has a fair amount of complexity, there are good chances a different design could lessen that complexity and the organization would be gaining from having external developers onboard more easily.
Then again, when we start with a system in this state, no single change that can make a difference will happen overnight.
I hope this is simply something that is not affecting how much you enjoy the work itself.
I'm sure there is plenty of work to do. Good thing they have you on the team now.
1 Like
I’m in that kitchen and I’m being asked to find articles that are somewhere in one of those newspapers.
I do appreciate that a tidy working environment has benefits. A tidy graph reveals all sorts of dynamics. It illustrates the network matrix
3 Likes
I also have one: here is the relationship graph of a customer database. Before and after. I didn't change any relationships, I just tidied them up thoroughly. As you can see, this makes it much easier to work with and understand the relationships. If it were up to me, the anchor TOs would also be separated from each other. But that might come later...
For privacy reasons, I have deliberately kept the resolution of the image low.
7 Likes
I've inherited once an application like this. This is really unmanageable.
And it is not a matter of cleaning up.
Only one solution will be future-proof: a complete rewrite with a block structure instead of spider web structure.
The re-organisation makes such a big difference.
The oranising principle of my messy graph is to place table occurrences together when they have the same base table.
Once you have collapsed all the TOs, it usually looks much tidier because all the connecting lines of a base table only converge on one point. Then you can move all the anchor tables to the left and place the buoys to the right.
I wouldn't do that, because it sounds like a lot more work. A spider structure is actually nothing more than an anchor-buoy structure in which the base tables have been (wrongly) connected. If you separate them (and create new relationships instead), then you have a clean structure where not everything is connected to everything else.
After that you name the TOs according to a continuous naming convention and the whole thing is finished.
The challenge here is to find out where the deleted relationships are used in the database and replace them with the newly created relationships so that nothing breaks. Probably not feasible without a tool like FMPerception.
I would say the two are fundamentally different beasts. A spider structure tends to be more compact than an anchor-buoy structure for a same given solution by virtue of avoiding duplicate relationships. The approach to designing either are very different… if efficiency, legibility and so on are valued.
I'm in agreement. Modifying the graph by moving things around until no lines cross is not destructive. It can be revealing and informative. However, modifying relationships, especially connections between relationships, is destructive. It may destroy data integrity. It may introduce errors into scripts. It may break the user interface.
With a big system the number of layouts and scripts makes broadscale change difficult. As an example, I queried the XML output of the system for the use of a script. It's called in more than 2500 places, from layouts and in other scripts. We have to discuss whether it is better to introduce an IF in that script. We don't have an accurate idea of how often the IF will be needed. It maybe a few times, maybe hundreds. Do we add extra code in the script, or do we handle the exceptions in the layout? It's always a decision that has to consider many different factors, including maintenance of the existing codebase and development for the future.
Looks like the Web is not only in the Relationships Diagram. I guess no one has a thorough understanding of this system. The job is frightening and inspiring, and what a challenge !
I wish your customer will have the patience to follow you, such a system overhaul will not be completed in a few weeks.
Since we are working often on solutions somebody else (and those solutions grow...) created, we got a lot of such (and even worse) spiders. When working on a application like that, one of the first things is to reorganize the graph (without changing anything else) to get a better overview and so that one can find nodes.
The worst thing is, when also the naming is bad. There are applications out in the wild with naming like ProProHubaGaga ('Huba' and 'Gaga' are fictional, the 'ProPro' is real (sometimes even 'ProProPro').
As a result, the original developer picked the wrong TO and deleted the wrong record. Fantastic!
1 Like