2006/8/9, Ilya A. Volynets-Evenbakh <email@example.com>:
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.
I really don't like the ideas of ACL and global ids. Probably, we can solve this the way unix does - we already have the object owner, we may also have a group of apprenices :)
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 words.
I have developed several databases. The two of them that use the convention as it's described now are the most convenient for everybody who uses them. For the small size database as we are building (I expect <50 tables) the two-letter prefix is enough to uniquly identify the field in the database. For the TTS database, with ~120 tables, I even had to use a mix of two- and three-letter prefixes. Still, when implementing something or discussing something, it allows to name just the field name - and everybody understands what you're talking about. So, I'd like to keep it the way it is.
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.
It's a table of solutions for a problem. Come up with better name. As for XML - I didn't come accross the description of how it should be stored. XML is the universal way, a container.
4. What is "study_testing" table?
There is a reference to the course testing, or something like this. I'm not sure - how it's related to anything yet.
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?
I can and I will - as soon as we get the general skeleton more or less formed.
6. Keywords: what is intent behind all the _keywords tables?
These are just proxy tables between actual keywords table and an object, just two foreign keys per row. I didn't want to store separate lists of keywords per object type, however it's possible and I don't insist much.
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 ;-)
Yeah, I thought about it. The XMI file is a text file (XML) - so it should stand corrections (merges) through CVS. However, I have discovered, that simply removing one important section may make the XMI file unreadable for umbrello. It reads such file, but shows no diagram - only object types and tables (on the left).
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 http://www.total-knowledge.com
-- Alexey Parshin, http://www.sptk.net
Authoright © Total Knowledge: 2001-2008