Welcome to Forums Sign in | Join | Help | Forums
in Search


Best way to code const. & attributes for an easy retreive

Last post 06-12-2008 2:55 PM by Melissa Graves. 1 replies.
Page 1 of 1 (2 items)
Sort Posts: Previous Next
  • 06-12-2008 2:27 PM

    Best way to code const. & attributes for an easy retreive

    As a new user charged with organizing the database there are a lot of options. We're small and have about 15 const codes and 30 attributes. We need to add more. It seems easiest to just keep adding them here. BB staff mentioned further breaking out attributes using the table feature. The problem is, you have to click on the field next to the attribute ("description") to know if there is a table for further definition. Not everyone will remember to do that. Any reason I can't just keep it simple with constituent codes and attributes?

  • 06-12-2008 2:55 PM In reply to

    Re: Best way to code const. & attributes for an easy retreive

    Keeping it simple varies in the eyes of the beholder.  Simple for the user, simple for you, simple for the report writer, or simple for the database?

    There are best practices for optimal database structure and adding dozens of fields which could optimally be one field with dozens of table entries is simply not good structure.  It may not seem to be an issue now but down the road there will be times when it could make things difficult for you and for the database to process. When entering an attribute you have to click in the description no matter whether you use a table or not so that concept makes no sense to me. 

    A query of :

    Attribute A = X
    OR Attribute B = Y
    OR Attribute C = Z, etc., etc., etc.,

    will process differently and less effectively than

    Attribute D is one of X Y Z, etc. etc.

    If these are mailing codes the more you add the more chances people will forget that attribute M is a mailing code (along with Attribute A, B C, K, N, R, and S)  and forget to remove/add them from/to your mailing where if they were all in one table as Mailing Codes you are more apt to deal with everything in that table in one query criteria.

    The thing about databases is they store information effectively to be able to query and report easily.  In the days before databases analysis and reporting took so much work from lists and spreadsheets.  You made a list of this group and a list for that group but people on 2 groups were not linked so you had more work to do when trying to report on the 2 groups.  Databases gave everyone the impression that everything is easier - in fact a lot goes into populating a database so the work is on the front end making analysis and reporting easier.  Trying to make things easier on the front end will only bring you back to the time when things were easier on the front end but more difficult at the back end.

    I have 7 constituent codes and 10 attribute codes and manage a medium sized database fine. 

    Melissa S. Graves
    Annual Fund Development Services Manager
    Pathfinder International
Page 1 of 1 (2 items)