New keys and indexes

[Piratos]

You should make a new set of keys in your cms to make it clean and faster.
Now the sets are not the best and with wrong performance.

I have tested this with the best result:

  Table content
  PRIMARY KEY  (`content_id`),
  KEY `content_alias` (`content_alias`),
  KEY `hierarchy` (`hierarchy`),
  KEY `owner_id` (`owner_id`)

  Table  module_news_categories
  PRIMARY KEY  (`news_category_id`),
  KEY `hierarchy` (`hierarchy`)

  Table modules
  PRIMARY KEY  (`module_name`)
 
  Table adminlog
  PRIMARY KEY  (`timestamp`)

  Table htmlblobs
  PRIMARY KEY  (`htmlblob_id`),
  KEY `htmlblob_name` (`htmlblob_name`)
 
  Table users
  PRIMARY KEY  (`user_id`),
  KEY `username` (`username`)

  Table module_deps
  PRIMARY KEY  (`parent_module`)
 
  ----------------------------------------------------------------
  In your initial.sql are some inserts ('headtags') with duplicated keys in table content_props

[Doug]

Interesting...

Has anyone else verified this?  What do the developers think?

[Ted]

Sorry, I've been out of town.  I totally agree that this should be done and I'll get it into svn as soon as I can.  Going to verify it all, of course, but at a quick glance it looks correct to me.

Nice job

[calguy1000]

For everybody's information, we've decided to go through and do a general review of keys and indexes in the cmsms core.

We'll start with pyratos' ideas here, and also draw up a list of the most commonly used queries in cmsms, and from that we'll modify the schema to set whatever keys, and create whatever indexes are necesssary.

[Trekkie101]

Quick note to anyone working with keys ever

Primary keys should be created on unqiue fields only, and only make things a key if its a foreign key in another table, otherwise dont make it a key.

Unless its supposed to be a compound key to support something else but in general try and use a little keys as possible