Re: [Simplog-devel] adodb

[Jim Hu <ji...@ta...>]

Jason,

I think it's logical for you to build on the security stuff that you 
have started on.

For the attributes, I'm not sure if you are still thinking in terms of 
the schema diagram you sent the other day.  It's taken me a few days to 
find the time to look at it.  As I understand it, the benefit of this 
is that modifications can be built into 1.0 without having to change 
the underlying schema.  Although it seems contrary in some ways to my 
really primitive understanding of database normalization (i.e. that it 
would make sense to have additional columns), it seems to me that your 
idea is basically a good one in terms of upgrade paths and 
standardization.  If I'm following your thinking, the set of attribute 
tables is basically a catch-all for extra fields that people could add 
on top of 1.0.  It would allow something similar to a plug-in model for 
customization where an added php module could use attributes in these 
tables and not touch the underlying schema.  If that's the idea, I like 
it!... especially since I've already gotten out of sync with everyone 
else by splitting my date fields in blog_entries into both created and 
modified.

However, the schema you sent seems more complicated than necessary to 
my naive eye.  What is the problem with handling the attributes with 
just one additional table instead of four?

CREATE  TABLE `attribute`  (
`attribute_id` INT UNSIGNED NOT  NULL  AUTO_INCREMENT ,
`table_name` INT UNSIGNED NOT  NULL ,
`foreign_key` INT UNSIGNED NOT  NULL ,
`attribute_key` VARCHAR( 10  )  NOT  NULL ,
`attribute_val` VARCHAR( 10  )  NOT  NULL ,
PRIMARY  KEY ( `attribute_id`   )
);

To use your example, to set blog number 4 to allow rss, a row would be 
created with values ('','blog_list','4','allow_rss','true')
and retrieve the info with something like:

SELECT attribute_key, attribute_val FROM attribute, blog_list WHERE 
table_name = ' blog_list'
	AND blog_id = foreign_key AND blog_id = 4 AND 
attribute_key='allow_rss';

To get the list of blogs with rss feeds, you'd change to something like:

SELECT blog_id FROM attribute, blog_list WHERE table_name = ' blog_list'
	AND blog_id = foreign_key AND attribute_key='allow_rss' AND 
attribute_val='true';

and so on. From what I understand, this simpler schema would lose the 
ability to specify which attributes are allowed, and which key=>value 
pairs are allowed...but what is the cost of that?  I'm thinking that 
this could just as easily be controlled from the php interface 
side...but I'm sure I'm missing something, as your schema looks more 
like what I remember from my one intermittently audited db class.

Whichever way attributes are handled, it also seems to me that in 
integer releases those modules that are most useful should be rolled 
into new columns or tables in the core schema. Between integer 
releases, new functionalities would use the attributes table, and 
ideally the overall software scheme could be modified to make things 
modular so that just like the core schema, the core php files don't 
have to change for new features, just for bug fixes.  I'm not 
completely sure how I would do this, but I'm thinking of something like 
this:

class.BlogInfo would add methods to handle attributes.
lib.php would include a line include("plugins.php").  plugins.php would 
be a list of include statements for plugin modules, which would live in 
a plugins folder.

In addition to the rss example, it seems to me that attributes could 
control many of the features that have been discussed/requested, 
including applying different css files and layouts to different blogs, 
closing comments on specific blog_entries, and so on.

Just my $0.02.

Jim

On Sep 21, 2004, at 11:37 PM, Jason L. Buberel wrote:

> I'd like to make one (hopefully the last for a while) infrastructure 
> investment in the database schema - to allow us to flexibly add 
> attributes to various tables in the DB without having to add new 
> columns to existing tables all of the time.
>
>  design email with diagrams to follow shortly.
>
>  i'd like to take a pass at the security overhaul, fwiw.
>
>  -jason
> <snip>