Re: comments on database format

[Wade Hampton <whampton@staffnet.com>]

Jason Pincin wrote:
> 
> > > It will be handled outside of the actual object's table.
> > Should the table contain the latest version number, e.g., the ?  Also,
> > are you using
> > RCS/CVS?  The version number could be the ID from RCS?
> 
> Thats a good idea.  Ther article table should perhaps indeed contain the
> current version number.  Of course, this would be a read only field,
> handled entirely by commit().
> 
> No, I'm not using RCS/CVS for object versioning.  It will be implimented
> within the object code I've done.  There will be historical tables that
> maintain historical values for objects.  Not sure on all the specifics
> yet, as I don't have it done... but you can probably see where I'm going
> with it.
You may want to have a "prune" or "archive" method that allows you to
export previous versions to an archive (arch_id.sql.gz?) so you can
prune
your database and not always keep old versions on-line (especially when 
this gets REALLY big!).
> 
> > > confusing.  The Permissions table will track what objects are able to perform what actions on
> > > what objects.  Thats the structure it'll follow.  And that will allow all objects in the system
> > > to be security aware.
> > Does this add a lot of overhead?
> 
> Not sure how much overhead yet.  It will definately increase the query
> overhead of $current_user.  BUT, I'll probably do it in such a way that if
> permissions are not checked, the $current_user object does not do the
> query.  When the first permission is checked it will set up the user's
> permission structure, so subsequent perm checks will not cause subsequent
> DB querys.  Only happens 0 or 1 time.  This should bring the hit in
> performance down.  We'll see.
SOunds reasonable.  I assume these are PHP objects and if so, I need
to do a bit of research into that (I know C/C++ and basic PHP).

Cheers,
-- 
W.