Re: [Phpgroupware-developers] Account/Address DB proposal

[Alex Borges]

El lun, 07-07-2003 a las 21:21, Michael Dean escribió:
> I've followed the thread, but dropped out of discussion because the
> schema was completely tanked.  It was not a concept schema - it already
> has code behind it and is in use AFAIK.  I made my points, it wasn't
> accepted, so I have nothing else to add.

No, even if we do have some work behind it, no app as of yet depends on
it and there is no plan to break the current interface (no rewritting in
0.9.16).

The idea is that we have to try and accomodate as much as we can for all
necesities, so maybe you can try and help other app designers (we are
writing with developers as clients in mind), including us, to work
arround the dcl design to accomplish the same. Namely, scalable contact
types (we have ppl, organizations and now maybe we will also have
resources such as buildings or rooms, devels have said they want to
easyly scale this kind of things), have a design that is as normalized
as possible, have contacts be able to have messaging types pulled from a
catalog so those types can easyly scale in time, have persons belonging
to zero or more  organizations, have organizations that have 0 or many
persons. Organizations should be able to be in a resource such as a
building or spawn many buildings. Persons should be able to be found in
resources such as a conference room, or a particular office number
(hence, resources that are rooms), ...Etc. Etc. Etc.

While we can debate that the design is very heterodox (well, no, no
debate there...;)...), i think that we are trying to accomplish a more
general schema here than the ones weve seen so far from all
participants. This doesnt spawn from greatness, coolness or anything. It
comes from having talked to most and trying to accomodate to all.

Maybe we dont have your experience, but i shure would listen if you
would make a larger, more comprehensive critique of the schema as is, of
the design and the ideas of what we are trying to accomplish behind. 
Let us post the latest revision, ill let you know, and you can help us
revise it.

Please mike, i know you have a lot of other work to do, but youre the
elder here and it wouldnt hurt to hear your full fledged oppinion at
all.

We are still in the design fase, yes, i pushed a bit because of time
constraints, but we are still designing classes, very few code is
actually already done.

I wanted to wait until the concept was more developed, but well. Here
goes:

Along with this more complex db schema, we have to design a layer that
will simplify the use of the addressbook. We cant simply export the
schema to classes and let the user handle its complexity. We also cant
just keep this read() function we had until now because it makes more
sense to let the user make more speciffic queries (through calls to the
contacts api) that translate to very speciffic and efficient sql code.

Here i speak for jarg, eald and myself. 

So at the first layer, weve thought of a way to abstract some of the sql
through a sql class that youd use to produce SQL code. 

Sql abstraction is provided through and abstract class that has methods
that generate LIKE, EQUAL, AND, OR...etc. statements out of the
parameters you send them. You can nest the calls to them to build a
whole complex querie and that ends up in sort of an infix notation to
express sql in the php language. Yes. Its not so hot right now, why not
make the sql up front? 

The framework though, does not depend on this methods to work, the
methods are just a plan for the future when we might want to reimplement
all classes for a given database backend so that we use subselects in
postgress, where-join oracle notation in oracle, and simple sql in
mysql.

In comes the second layer: Well, we can have a class per table, each
class would inherit from that abstract sql class and thus, would have to
comply with the basic interface. But each of the new classes would
'know' how to join to the classes they are linked to in the diagram. To
build a simple query it seems like too much work, to build a complex
one, that involves any probable ammount of tables (like the current
read() method), takes 50 lines and introduces no (zip, nil, zero) nested
loops. Therefore reducing complexity from O(n^2) to O(n), and from
hundreds of lines to a few tenths of them .... so, potentialy, this is
faster than it was, and we have lots and lots of new features. 

When we have more ill post some examples. One idea to keep in mind is
that none of the classes in this layer loop through arrays or hashes
(although it does access hash information directly). It ONLY generates
SQL. A potential benefit of this structure is that parts of the query
can be cached thus, if you make a query that returns more than 50
results, you click on the next button and the query wont be rebuilt,
just the LIMIT element will be changed and reappended to the query.

Okay so the third layer, which is what most devels would use, would
provide for a direct, CRM oriented api interface. Youd be asking for ppl
within an organization, for a number of address entries for an
organization with a given name, for all the organizations that have an
email, for all fax numbers of all organizations that have more than 20
employees..... etc. 

Exactly what methods will the third layer be providing? Well, mostly
whatever the
calendar/rbs/infolog/email/jsaddressbook/addressbook/todo/notes/timetrack/projects
 need right now. With some ideas so that other apps (ck-ledger should) are 
compeled to use them.

So, it aint as bad as you might be thinking michael, but we would shure
miss your guidance on this, especially knowing that you really dig oo
programming and design and that you have more experience than most here.

> 
> The DCL/GNUe definition of the contact schema will not change from the
> original, with the exception of renaming the accounts to orgs (since it
> confuses everyone) and adding a configurable contact method schema
> (Jabber, ICQ, etc).
> 
> On Mon, 2003-07-07 at 14:31, Alex Borges wrote:
> > El lun, 07-07-2003 a las 09:15, Brian Johnson escribió:
> > > Some is good, some can be handled by current proposal (if provided for in 
> > > ui), and
> > > some I don't understand it's purpose/need
> > > 
> > > IMO, we should work in conjunction with mdean of dcl to develop a new db 
> > > model for
> > > both projects since dcl is part of gnu enterprise
> > > http://www.gnu.org/software/gnue/project/what.html
> > 
> > I thought we did that. Mike is shure reading all of this.
> > 
> 
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>