Re: [regrep] SQL Schema Comments

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Goran,

Thanks so much for the thorough review of SQL Schema and the thoughtful 
comments. They have uncovered several bugs. In some casesI suggest no 
change and give my reasons. Lets discuss in today's special meeting. Thanks.

Goran Zugic wrote:

> - home and lid are URIs. Is their length 128 or 256?

+1. Will fix in draft 02
URN and URI are 256 chars. Since id is now a URN both home and id MUST 
be 256 chars. home already is.

> - What is the reason that VersionInfo is flattened in all 
> RegistryObject-based tables?

There are many cases in the schema where we flatten columns for some 
composed classes into columns in the containing class' table.
See for example Person and PersonName. It avoids a join. This is an 
optimization we have always done where it makes sense in
the relational binding.

> - AffectedObject does not match rim.xsd definition (eventId is not in 
> rim.xsd, createReplica is not in AffectedObject)

That is because AffectedObjects are composed within AuditableEvent and 
in XML Schema and UML their composite object is implicit.

> - Can we add MimeType as a canonical ClassificationScheme. If we do 
> so, mimeType's datatype in ExtriniscObject will become varchar(64)

The spec is complicated for that. It is hard to get it right. Would it 
be a flat or multi-level hierarchy? Which mimeTypes should we include 
canonically?
Sometimes specifying too much is not desirable and I think this is one 
of those cases.
Also it is a fair amount of work that I do not think is worth the effort 
for version 3.

> - Can we also add Lang and Charset as canonical ClassificationSchemes. 
> If we do so, all lang and charset columns will have varchar(64) datatype

Same as previous comment.

> - createReplica is missing in ObjectRef

That is because createReplica is only needed for request processing when 
submitting an ObjectRef and serves no purpose once the request has been 
processed.

> - PostalAddress, EmailAddress need id because of Slots

This is a good issue. We could make them derive from Identifiable and 
remove the Slots within their definition since that would be inherited.
On the other hand it is an open question in my mind whether we need to 
make them extensible which has extra storage cost. Would this
be a useful feature (extensibility of PostalAddress, EmailAddress etc?). 
What do folks think?

> - operator's length in Registry should be 256

+1. Will fix in draft 02
Now that id is a URN all reference attributes including operator MUST be 
made 256 chars.

> - specificationVersion in Registry should be not null

+1. Will fix in draft 02

> - Slot table should be transformed into two tables: Slot and SlotValue 
> (Second Normal Form)
>   Slot columns should be: name, slotType and parent with (parent,name) 
> primary key
>   SlotValue columns should be: name, value and parent with 
> (parent,name,value) primary key

That would be an extra join. What does that buy us other than a 
performance hit? Suggest no change.

> - subscription is missing in Notification

+1. Will fix in draft 02
It is also missing the ObjectRefList mapping. This will require a 
separate table like AffectedObjects probably called NotificationObjects.

> - person_firstName and person_lastName in User_ should be not null

In 3.0 these attributes have become option so no change is needed.

> - What is Person table used for?

To record persons. Just as Organization records Organizations. Persona 
and Organization are an important and commonly used metadata.
This class was added with TC approval based upon Paul Spencer's request 
for enhancement based on user feedback. Note that Person class is also a 
base class for User class.

> - Informal RDBMS naming standard is that multi-word names for database 
> objects (tables, indexes, etc.) have underscore between
>   "the words". For example, classification_node.

I am not aware of such a (informal) convention. I suggest no change because:

-There is no string convention on this
-It is better to align with our classnames as a matter of convention

-- 
Regards,
Farrukh