Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: First portion of data structure to start from

Alexey Parshin wrote:

Please, consider this structure as a proposition and not as a statement.

I surely got it this way, don't worry!

2006/4/30, Anatoly Volynets <av@total-knowledge.com <mailto:av@total-knowledge.com>>:

    Now, I want some clarifications:

    Person to Course relation:
      Type: many to many ------ means many people can relate to the same
    course, while a person can relate to many courses
        type (student/apprentice/author) ----- so these are fields of the
    intermediate table?

1) Yes 2) No, these are the possible values for the field "type" (assumed the referrence to some table of three or more rows)
    BTW, I am not sure, I remember what exactly an apprentice is here? A
    co-author or teacher with some limited rights or a student with some
    expanded duties (makes sense if we talk about a group of
    students)? Any

IMHO,  an apprentice is a trusted student, with some extra rights/duties.

I believe we do not need Aprentice. I think it used to be just another name for student.

    Topic to Required Topics relation:
      Type: one to many ----------- means a topic can be optional or
    mandatory? We have related issue in specs: prerequisites for a topic,
    but it seems to be much complicated. There can be many
    topics/courses/texts/problems/tests/games/other objects
    pre-required for
    the given topic, or course,  or  problem, or  game, or....  Thus we
    need  to  provide  one-to-many prerequisite-relation for an object
    in a
    course to objects from Repository (I start to think)?

Means - a topic may require an optional list of other topics. And yes, this is one of the required relations, probably the most important. It means - the person can't start topic if he/she didn't complete the required topics.

We do not have it in specs and I think now, we need some more generic relation - see my previous note (some kind of object-objects one-to-many). I'll put it in specs. Let me make up my mind :)

    Keyword to Topic relation
      Type: one to many

    One keyword an be used in many topics, courses and so forth, while
    keywords can be used in a course, topic, explanation, etc. So it is
    many-to-many and involves many objects, not only topics.

Yes, however if we do it this way - we have more complicated structure with not so much of the gain. It may be done both ways, with some pros and cons.

Well, many keywords for an object - is plain reality. Having many objects for a keyword makes it possible keyword-based search. Am I right?

    Explanation to Topic relation
      Type: one to many ---- if one-to-many, then Topic to Explanation:
    there supposed to be many explanations for a topic

    Explanation to Person relation - I'm not sure we need this at all
      Type: one to many

        reference to source, ---- Why we need this? If an author refers
    students to a text from Repository instead of writing his own text
    field)? I think this situation does not differ from usage of other

Don't you want to know - where (from outside) this text came from? The Bible, a book, etc.. It's optional.

As I said - in this case an object "explanation" is originated from another object "text" and as such have to bear the "origin stamp". OTOH, normally, explanation is a regular text, written by its author for this course. If there are just regular references like in a regular book, we have to think how to put them there. Probably, plain web-links to outside-uu sources?

Alexey Parshin,


Anatoly Volynets, Co-Founder

Authoright © Total Knowledge: 2001-2008