The Great Tree

[Erik]

So you want a tag to be followed or not depending on the parents? Is that right?
It's possible... but it would really create the database overcomplicated and slow everything down if you ask me. Everything would have to be changed, while this is a rare case.

[Durin Mephit]

Yes, Erik...

I know it's complicated. It's going to be challenging to come up with a way of building this tree that doesn't bog the system down and require many queries just to generate a single page.

I'm trying to see the benefit of organizing by parent rather than by child, but you can probably explain faster than I can figure it out

I'll list some additional tags and how they're supposed to work, so the example is a little more thought out.

'mystonline' and 'uru' are non-primary tags associated with 'moul', which is attached to a site.

'incavern' and 'incharacter' are non-primary tags associated with 'ic', which is not attached to a site.

'drcwebsite' is a non-primary tag associated with 'drcsite', which is attached to a site.
_________________
Durin Mephit * Member of Guild of Messengers - Unless otherwise stated, opinions are mine only and not Guild endorsed.
rel.to | Marten KI: 59474 | Durin M KI: 11883768

[Erik]

In the future new tags will be created.

Let's assume that I want to make to make a new tag called X, that has parents A, B and C.
With the current table lay-out, I can fill in (for the tag X) for parents "A;B;C".
So:
1) When making tag X -> set children to A;B;C

If a tag would list children instead of parents, it would be like this:

The script will have to require the parents from the database (A,B,C). After that, the children for A need to be updated, the children for B need to be updated and the children for C need to be updated.
So:
1) Require the id's of the parents for X
2) Retrieve the children from A
3) Add X to the list of children and update the record for A
4) Retrieve the children from B
5) Add X to the list of children and update the record for B
6) Retrieve the children from C
7) Add X to the list of children and update the record for C

Instead of 1 query you would have 7 queries and on top of that, you have to 'mess' with already existing tags. There is no right or wrong way here, but it just seems better to me if you can leave all the old tag untouched when creating new ones.

I hope that explains why I chose to list parents instead of children.

EDIT: About the last part of your post: you want a good set of substitutes for each tag. What if a new column called "synonym" or something is added to the database.

Like:
ID: 100
name: drcwebsite
parents: (empty)
follow: (empty)
synonym: 5
When someone requests the tag drcwebsite, the script will look if the synonym column is set. It is set to 5, so the script will use the details of record 5 (drcsite) for drcwebsite.

Something like that?

[Durin Mephit]

That makes a lot of sense, Erik; but I was wondering what sort of query will be used to build the tree if the relationships are designed in the opposite direction.
_________________
Durin Mephit * Member of Guild of Messengers - Unless otherwise stated, opinions are mine only and not Guild endorsed.
rel.to | Marten KI: 59474 | Durin M KI: 11883768

[Erik]

Like I said here

[Durin Mephit]

I'm confused, Erik. But that's ok, it's common these days.

[Erik]

That is because of what you wrote earlier:

[dcos]

Uh... yes, I agree.

[Durin Mephit]

Alright. Um... yeah. I missed that part without the context.

Next question?
_________________
Durin Mephit * Member of Guild of Messengers - Unless otherwise stated, opinions are mine only and not Guild endorsed.
rel.to | Marten KI: 59474 | Durin M KI: 11883768

[Durin Mephit]

Erik,

Do you have any spare time to do some more thinking on the proposed design?
_________________
Durin Mephit * Member of Guild of Messengers - Unless otherwise stated, opinions are mine only and not Guild endorsed.
rel.to | Marten KI: 59474 | Durin M KI: 11883768

[Erik]

Not sure, but I'll see. Perhaps the whole database lay-out needs to be revised now that I understand you better, so that it is a bit more flexible.

[Durin Mephit]

Agreed. If you have any ideas on how we can "flatten" the db... maybe one approach is to only, ever, drill down one level... and if someone clicks on one of the children, any grandchildren then appear.
_________________
Durin Mephit * Member of Guild of Messengers - Unless otherwise stated, opinions are mine only and not Guild endorsed.
rel.to | Marten KI: 59474 | Durin M KI: 11883768

[Erik]

Sounds like a good idea, then the pages would load faster. It would take quite some performance if the complete tree would be built every time. It would also make the idea of children somewhat useless: why go to such lengths to create a good structure if all (grand)(grand)children are displayed anyway.

On a side note, I went to a software development company recently for teaching practice. It's a company that works with huge database structures for their applications (they create software for universities and scientific institutions among others, so these applications are huge!). So I got to see how they worked, saw a few bits of source code from smaller projects, talked with the owner of the company who told how they made a design for their projects, how they came to a good structure for a database. Things like that. It was pretty cool.
Anyway, one of the tools they used to come up with a good structure for a database was creating a entity-relationship model. I'll see if I can create a similar diagram for Rel.to. Perhaps that makes it easier...

[Durin Mephit]

I've standardized the look and feel of rel.to's pages although it isn't the final appearance by any stretch of the imagination.

I added a new page ("personal"). I also have started adding new links to all of the pages; I had a backlog of notes that I hadn't incorporated, and I still have more to process.

Some of the pages are getting a bit long
_________________
Durin Mephit * Member of Guild of Messengers - Unless otherwise stated, opinions are mine only and not Guild endorsed.
rel.to | Marten KI: 59474 | Durin M KI: 11883768

[Durin Mephit]

The "directory" page is now gone; everything except the Embassy Nexus seems to fit better on another page.

For now, the Nexus reference is on the front page again along with other misc links that I haven't decided how to manage yet.

Stylesheet information has been extracted and dumped into relto.css.

Minimal links to a 2nd sublevel appear here and there... these are items that won't appear in the same listings once everything is db driven, but they'll be accessible by drilling down (asking for more information on a specific entry).

I'm thinking that in the database built pages, entries will look a bit like this: