Home Projects Jobs Clientele Contact


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

Database schema [was: UU tools]

OK. Here are few comments, with the fact it's initial draft in mind,
in no particular order.

1. Person -> course relationships.
Even currently we have more then just student and teacher in our system.
There are "experts" there are "independent object authors" (creating and
sharing objects other then courses), and in future there might be even more.
So, I think instead of creating separate table for each of these types,
we need
ACL table. Furthermore - this needs to be well thought through - here is
an idea:
why don't we make globally unique object IDs, and have single ACL table
for all
objects, not just courses. Again - I'm just throwing this random idea
out here, and
am not sure what disadvantages are to it.

2. Naming conventions. I suggest following changes to naming conventions:
    a. All database names should be in singular form
    b. Do not add group qualifier to table names. i.e. "person" instead
of "person_list"
        or "course_keyword" instead of "course_keywords".
    c. Respectively, we'll need to remove requirement for each table to
be at least two
I do not insist on these changes, but if you have good reasons to be
against these,
I'd like to hear them.

3. problem_solutions table
    a. Why is it named that way? Sounds like "problem" is more appropriate
    b. ps_xml - this is bit of misnomer, since not all problems will
have XML in this field.

4. What is "study_testing" table?
5. Documentation: can you add comments (fill out "Documentation"
property) for all
    tables, describing in short its purpose, and semantic relationships
with others, where
    it may not be 100% obvious?
6. Keywords: what is intent behind all the _keywords tables?

Another thing: I'm going to set up SVN repository for UU some time soon,
so we'll put
all these diagrams in there. Let's see how well can we cope with
conflicts in that ;-)

Alexey Parshin wrote:
> The attached file is the very draft sketch of some objects in the
> database. This is mostly to statrt the discussion than a real thing.
> I didn't add any UMO-properties here yet - that comes much later.

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Authoright © Total Knowledge: 2001-2008