Further to another post regarding Table Entry Definitions, a colleague and I had couple other ideas that we thought could be beneficial. - TABLE DEFINITIONS - At a higher level than the table entry definitions, have a synopsys of what the purpose of the table entries in a particular table should be used for. For example with the Constituent Code Table, what is the purpose of these table entries. Each organization that I have worked with has used this table slightly differently. So if you could define the purpose of a particular table, then you would have a reference point to determine if a new table entry is appropriate. Now I think these table entries should likely come pre-defined by Blackbaud (at least for the tables that come default with the software), but we as DBA’s should also have the ability to change these definitions as the need arises. These Table Definitions should also be included on the Code Tables Report to help us with our analysis and maintenance efforts. - TABLE FEILD MAP - Additionally we thought about including a field map on the Code Tables Report. The intent behind this would be to help the DBA know where a particular table points in Raiser’s Edge. The idea would be to list the Module the table is tied to, and the Field Name. For example with the Classifications Table, the table name itself provides not indication as to its purpose. But if the Code Table Report listed that this was part of the Prospect Module, tied to the field named Classification we would have the ability to quickly reference the system front end to better understand its use. - TABLE ENTRY COUNTS - The last idea was to have the Code Table Report include a count for each table entry. Often times during initial configuration we will set up a number of table entries, but there is no way to determine if these entries are actually being used short of creating a query on each table entry one at a time which can be cumbersome. Including a usage count on the Code Tables Report would allow the DBA to quickly discover if a table entry is being used and help facilitate table clean-up.

 Your Table Field Map suggestion is something you can already do.   If you run the Table Cleanup utility on a specific table the cleanup window will tell you what type of record uses the specified table.  If you haven't have any table entries, just create one and then run cleanup.  For custom tables, all it tells you is that it is an attribute table.  Also, I don't think it will tell you if a particular system-table  is also referenced by an attribute (ie. we reference the 'Rejection Codes' table for a Bank Relationship attribute).

 The Table entry counts report would be VERY useful. I have just started with a new organization and there are 100+ different attributes all over the system and every field table has hundreds of values. In order to tackle this issue it would be great if i had an easy way to identify table entries that might have been created but never used so i can delete them to start with..  There is a tallies report but it only reports on a very limited and rather random list of fields (ie. industry, etc.)