Re: [Simplecms-development] Database Layout

[Toni C. <ou...@gm...>]

[off-topic]
I agree with the ACL. Though looking at the levels you talk about I'm
not quite sure about the overall layout of the engine you're planning,
specially the level 100, sounds more like a wiki to me.
So, what seems to me is that when you speak of modules are you in fact
speaking of tiny snippets, and all content will be handled by a unique
component. Am I right? I thought more a phpnuke-like design so this
would change a lot of my assumptions. Please, clarify this point.

To put it with an example:
So, would http://example.com/whatever access the whatever content
page, handled by a "content" module, or would it access the whatever
module?

I believe planning first the architecture and/or classes
hierarchy/relations would be better.

[on-DB-topic]
* Anyway, the content table should have a string index if you plan to
have nice urls. If this voids the need or not of a contentID will
depend, but you most certainly want a string index whatsoever.

* Also you may want an 'enabled' field on the content table too.

I would have more comments but I must first understand better the
design details.

On Apr 1, 2005 6:34 AM, Jonathan Chan <jon...@gm...> wrote:
> Hello,
>  
>  This is my plans for the database layout... Please give comments if you
> think there should be other names for the tables/suggestions for improvement
> that would make the data be accessed faster...
>  
>  Jonathan Chan
>  
>  ==========================================
>  Database Layout
>  
>  This is the document I wrote while planning the database layout for
> SimpleCMS.
>  
>  
>  ---------------------------------------
>  Access Control List
>  The Access list is designed to provide a "single" uniform allow/deny list.
>  Every larger number will give the user more power. 0 is the user access
>  somebody not logged in would have while 255 is the highest access level
> which
>  gives the most power to a user. Because what one would consider as more
>  important or more "power" is subjective, the access list can be edited.
> Also,
>  1 number can be used by more than one "job" (ie. The userlist admin setting
>  can be the same as master editor (250)).
>  
>  Access Control List
>  255  -  Senior Admin; "root" access; Can modify anything and everything
>  254  -  Userlist Admin
>  253  -  Admin Developer Level; Can modify "core" module settings that can
> leave
>          SimpleCMS unusable.
>  252  -  Global Developer Level; Can edit "global" modules
>  251  -  User Developer Level; Can only edit "user" modules
>  250  -  Master Editor; Can edit all content pages
>  100  -  Insert Content into the "root" path (/); Can create new content
> page
>  
>  More may be added by modules.
>  
>  Table:ACL - Hold Access Control Numbers
>  
>  moduleID  - ModuleID that uses the ACL (small unsigned integer)
>  subID     - Definition ID for the module (small unsigned integer)
>  summary   - Short summary (1-10 words) of what the definition does.
> (tinytext)
>  level     - Access Level (0-255) (tiny unsigned integer)
>  
>  ---------------------------------------
>  Content Modes
>  
>  Read   - Determined by Content Table
>  Create - Determined by access list and content list
>  Edit   - Determined by Content Table
>  Delete - Owner or master editor
>  
>  
>  Table:Content - Will hold the actual page content.
>  
>  contentID       - Internal ID for the pages. Index. (small unsigned
> integer)
>  parentID        - PageID of parent page, 0 for root (/). (smallint
> unsigned)
>  userID          - UserID of the creator of the page. (smallint unsigned)
>  content         - actual content. (longtext)
>  date_created    - creation date (timestamp)
>  date_modified   - modification date (timestamp)
>  read_level      - min security level to view the page (0-250) (tinyint 250)
>  edit_level      - min security level to edit to this page (0-250) (tinyint
> 250)
>  create_level    - min security level to create pages under this page
> (1-250)
>  is_index        - boolean; true is index. (tinyint(1) unsigned)
>  recursive       - boolean; false if an error should be given if child
> doesn't
>                    exist; true if the parent should handle the module
> (tinyint)
>  
>  It is recommnended the read_level be between 0-10 for the most common uses.
>  
>  ---------------------------------------
>  Config
>  
>  Table:Config
>  config_name  - Config Name
>  config_value - Config value
>  
>  Miscellaneous config options may be stored here. Modules with only a few
>  config options may store config settings here too.
>  ---------------------------------------
>  User
>  
>  Table:Users
>  userID      - UserID
>  username    - User name
>  first_name  - First name
>  last_name   - Last name
>  email       - Email Adress for user
>  level       - Access level of user
>  
>  "Single Sign On" user database. This database may be expanded by use of
> joins.
>  (ex. we want to make a address book module, we just add a table "addr_book"
>  and just make joins to the userID.) The original purpose is to create a
> single
>  sign on so that each module that needs authentication does not need to
> create
>  their own database. This does not mean that people can not make their own
>  database if they want to write a module that should not use the same sign
> on
>  info as the management system.
>  ---------------------------------------
>  Module Database
>  
>  This table will hold the module database.
>  
>  Table:Modules
>  moduleID    - ModuleID
>  module_name - Module Name
>  summery     - Short (>10 words) of what the module does
>  enabled     - True = module enabled; false = module will not be loaded
>  
>  ---------------------------------------
>  
>  More tables may be added by modules, especially modules that provide large
>  services. A modules insertion documentation will be written later.
>  =============================================
>