RE: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

[Geoff S. <ge...@ho...>]

I agree that having an organizational unit id would be a great idea.
HOWEVER, that will not happen soon. I'd like to have the separate table
enhancement, because it is dirt easy to implement.

I'll take this one step further: I have a requirement that necessitates the
separate table in the same database solution. So, if the group doesn't agree
to it, I'm going to have to do it on my own and I'm REALLY going to hate
being in the position of having to maintain my own separate code base before
I've even set up my first phpWebsite. (I expect to have about 10 websites
running phpWebsite off separate tables within a single database by April
15th.)

Also, there is a security issue. If you setup separate tables for each sub
website, then you can grant access privileges separately to each sub-web. (I
don't think that mySQL implements row level security. Someone please correct
me if I am wrong about this!) If you store everything in the same set of
tables, you cannot use the mySQL security system because you can't assign
specific values in a column to a mySQL userid.

That means you must rely on the security in phpWebsite to control access if
you segment by using an organization id (OID) in the tables. (Not that
there's anything wrong with that.)

Now, I think that BOTH of these techniques have their place and are
appropriate for different circumstances.

The separate table technique allows separate database administrators to have
access to their data and no one else's via the database security system.
They could dump their data using a database utility, or whatever.

The OID technique provides user security, and admin security within the
context of phpWebSite. But, anyone who has access to the database userid and
password would have access to all of the data, not just their own.

So, BOTH of these techniques have their place in the design. The separate
table technique and the OID column technique can coexist without having any
impact on each other and will allow much more flexibility.

Now, here's another issue. I would like to be able to assign phpWebSite
administrators to various topics or pages within a website. This would allow
someone to setup a website and have an administrator for the "Linux" topic
and a separate administrator for the "Mandrake" topic. This would have to be
done programmatically through the phpWebsite administrative programs.

IMHO, all three of the above need to be part of the system.

Geoff
Hostricity.com
Dallas, Texas

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
Jason Campbell
Sent: Friday, March 23, 2001 3:22 PM
To: php...@li...
Subject: Re: [Phpwebsite-developers] Table Naming Conventions and
Multiple Instances of phpWebSite


I remember that post about it too now that your brought it up.  Its a very
good idea to get phpwebsite to be scalable but its bigger than changing one
thing in the config, it would be better to do what Todd quoted from the
other message about this option.  I'd be willing to work on it with whoever
would want to do this on the dev team.

I remember someone saying a new version of ADODB was released, before we
use one or the other I think we'd have to know how stable each are and
which one is more widely used by other developers.  Did this get discussed
anymore on which one to use, PEAR of ADODB???

Jason Campbell
Xplozive Media Technologies
phpWebSite Developer

> I agree multiple phpWebSites should run in one database, but I
> _disagree_ with the proposed fix.
>
> I am with Aaron and Jason; the sites need to share common tables.  The
> following is an excerpt from a March 6th post to the list.
>
> __Multiple Organizations
> If we want to make phpWebSite scale to have multiple organizations in
> the same database, then we need to add an additional field to each
> table such as "ouid" (organizational unit id) ["oid" is reserved for
> object id in Postgres].  The primary key for each table would need to
> be changed to (cid, ouid) instead of (cid) alone.  To prevent ouid
> guessing or spoofing, the user access control list (ACL) would have to
> be consulted for each page access, which should be done anyway.
>
> Since this change affects just about every call to the database tables,
> it seems to be a good time to add the database abstraction layer while
> we're at it.  Will it be PEAR of ADODB?
>
> --Todd
>
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers



_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers