Establishing relationships. anyone have a better idea?

[Hansvb]

Hi,

Does anyone have a better idea or points of interest for the following? ...

In my daily work I create all kinds of ETL procedures (Extract Translate Load). Which actually means that I am working with many different data in all kinds of locations. As long as I am building, I know exactly where everything is and what the consequences of adjustments are, but if I have to change a table after six months, I no longer always know what the possible consequences are without first view the data at all the locations. That's a bit of a waste of time.
So now I'm looking for a way to document that. I haven't been able to find any useful tools for this, but if anyone knows anything, I'd love to hear it.

Until now I had the idea (and already tested it a bit) to put a number of string grids on a form, separated by splitters). And then if items have a relationship, these relationships are displayed using a color.
At first glance it works, but if you have 10 string grids it becomes tedious to read and creating the relationships is labor intensive. I do this with checkboxes and then saving it in a SQLite databas which consists of only 2 tables. 1 with all individual names of the items and 1 relationship table.
The idea seemed nice, but I think it quickly becomes confusing. (to manny grids with to manny rows).

Hence the question. does anyone have a better idea for capturing relationships between all kinds of different (data) items? Before I start again with "my new MVP knowledge", see other thread.

[jamie]

You need a TTreeView structure.

The root names would be the master and all items under that tree per root is related.

[Edson]

I've the feeling you need to model the entity "objects related" by a class and store several of that classes in a list. Then you will need a View-form to show the content of the list with the possibility of delete/edit. The backend of that will be storing the list, in a database, file or serializing.

[Zvoni]

Ouch....this looks suspiciously like an EAV-Antipattern, which is "blegh"

[Leledumbo]

Ouch....this looks suspiciously like an EAV-Antipattern, which is "blegh"

I hate a term that makes me need to join 3 tables just to get a value of a single key.

[cdbc]

Hi Hans
I stumbled upon an interesting article by Graeme Geldenhuys, which seems to deal with the same sort of issue you're having, with regards to relations...
It's a short article with example code etc...
I dunno if it matches your case, but here it is:http://geldenhuys.co.uk/articles/relationship_manager.pdf
Regards Benny

[Hansvb]

Hi,

That wasn't what I was looking for but it does look interesting. I should definitely read that carefully.

What I have difficulty with is the representation of the relationships in the form. I now do that with stringgrids and colors. It works but quickly becomes confusing when there are to manny stringgrids in the form. I was actually hoping someone would know a better way.

[cdbc]

Hi
Have you had a look at e.g.: UML-modelling, I've seen tools doing some cool stuff with the relationships between objects, maybe one could /translate/ something like that to your use-case...
I know Delphi shipped some things with the architect versions ealier on, but I don't know about lazarus, of yet.
Food for thought:
https://sourceforge.net/projects/essmodelforlaza/
https://umbrello.kde.org
http://www.umlet.com/
Regards Benny