[stats-dev] names for ogr-verification stuff

Jim C. Nasby jim at nasby.net
Tue Feb 25 18:09:53 EST 2003


Damn, sorry I'm just now replying... I need to watch the inbox more. I
know you've done some renaming work on this, so take what I'm suggesting
with a grain of salt, since some of this stuff might already be fixed.

On Tue, Feb 11, 2003 at 02:16:57AM +0000, Chris Hodson wrote:
> ogr=# \d all_stubs
>                                       Table "public.all_stubs"
>    Column   |         Type          |                           Modifiers       
> ------------+-----------------------+----------------------------------------------------------------
>  stub_marks | character varying(22) | not null
>  stub_id    | integer               | not null default nextval('public.all_stubs_stub_id_seq'::text)
>  project_id | smallint              | not null
> Indexes: all_stubs_pkey primary key btree (stub_id),
>          all_marks unique btree (stub_marks),
>          all_stubproject_id unique btree (stub_id, project_id)

all_stubs seems a tad redundant; stubs would probably suffice. But,
all_stubs is clear, so it's not worth changing this.

You should probably index on project_id, stub_id. You already have an
index on stub_id, so lookups based strictly on stub_id can use that;
project_id,stub_id would support lookups based strictly on project_id.
 
> ogr=# \d donestubs
>       Table "public.donestubs"
>     Column    |  Type   | Modifiers 
> --------------+---------+-----------
>  stub_id      | integer | 
>  nodecount    | bigint  | 
>  participants | integer | 
>  good_clients | boolean | 
 
What's good_clients?

> ogr=# \d id_lookup
>            Table "public.id_lookup"
>   Column  |         Type          | Modifiers 
> ----------+-----------------------+-----------
>  email    | character varying(64) | 
>  id       | integer               | 
>  stats_id | integer               | 
> Indexes: idlookup_email_lower unique btree (lower(email)),
>          idlookup_id btree (id)

This should have participant in the name somewhere, so it's clear what
ID means. I know stats is just as bad in this regard, but it also
shouldn't have any field simply called 'id'. I think calling this table
participants would be fine. id should probably become stats_id, and
stats_id should become effective_id (assuming that stats_id is what
takes retire-to's into account).

> ogr=# \d logdata
>              Table "public.logdata"
>    Column   |         Type          | Modifiers 
> ------------+-----------------------+-----------
>  email      | character varying(64) | 
>  stub_marks | character varying(22) | 
>  nodecount  | bigint                | 
>  os_type    | integer               | 
>  cpu_type   | integer               | 
>  version    | integer               | 
 
Perhapse log_import would be a clearer name for this.

> ogr=# \d platform
>                                   Table "public.platform"
>    Column    |  Type   |                             Modifiers                  
>            
> -------------+---------+-------------------------------------------------------------------
>  platform_id | integer | not null default nextval('public.platform_platform_id_seq'::text)
>  os_type     | integer | not null
>  cpu_type    | integer | not null
>  version     | integer | not null
> Indexes: platform_pkey primary key btree (platform_id),
>          platform_all unique btree (os_type, cpu_type, "version")
 
Depending on what type of lookups you're doing here, you might want to
include indexes on the other fields. This table almost never changes, so
it would be hard for you to have too many indexes on it.

> ogr=# \d stubs
>         Table "public.stubs"
>     Column    |  Type   | Modifiers 
> --------------+---------+-----------
>  id           | integer | 
>  stub_id      | integer | 
>  nodecount    | bigint  | 
>  platform_id  | integer | 
>  return_count | integer | 
> Indexes: stubs_all unique btree (id, stub_id, nodecount, platform_id),
>          stub_id_count btree (stub_id, nodecount),
>          stubs_platform btree (platform_id)

This is the big one that needs to be renamed. I think log_data would
actually be a good name for this table.

-- 
Jim C. Nasby (aka Decibel!)                    jim at nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
--
To unsubscribe, send 'unsubscribe stats-dev' to majordomo at lists.distributed.net



More information about the stats-dev mailing list