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.
> 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
>       Fields:
>         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
>     suggestions? 
> IMHO,  an apprentice is a trusted student, with some extra rights/duties.
Kind of like TA in US. Question is what exactly these rights would be?
>     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.
What does "complete" in this context mean to you?
>     Keyword to Topic relation
>       Type: one to many
>       Fields:
>         keyword
>     One keyword an be used in many topics, courses and so forth, while
>     many
>     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.
Can we try the "full-text" search approach instead? I'm not sure on the
details of this
technology, but I know it exists in some database engines. Could be
better then trying
to implement pure keyword searches on our own.

>     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
This could mean different things. Relation 1: Explanation and its author
Relation 2: Explanation and student, if he read it. Relation 3 (this one is
not direct): explanation and referrer (i.e. someone using explanation in his
>     Explanation
>       Fields:
>         name,
>         reference to source, ---- Why we need this? If an author refers
>     students to a text from Repository instead of writing his own text
>     (next
>     field)? I think this situation does not differ from usage of other
>     objects.
>         text
> Don't you want to know - where (from outside) this text came from? The
> Bible, a book, etc.. It's optional.
Does "Source" in this case mean "External Source"? If so - do we need to
have separate field for it?
And besides - if we use external sources (i.e. for indexing/searching
purposes), we'll need one-to-many
relationship here.
>     Person
>       Fields:
>         first name,
>         last name,
>         address,
>         email
>     Topic
>       Property of: course
>       Fields:
>         title,
>         summary,
>         problem ------- there can be a lot of problems within a topic 
> Then we just need another table, "Problem".
>     Property of: Topic
>     Fields:
>        name,
>        description
> -- 
> Alexey Parshin,
> http://www.sptk.net 

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Authoright © Total Knowledge: 2001-2008