It's different for each file and the objectives you're trying to reach. If
you are completely sure that the field's data will be unique (or you need
to enforce uniqueness) then sure. You just have to understand the
consequences. You wouldn't want uniqueness on fields like person
names. Hey SSNs are always unique, right? :)
At 06:48 PM 7/17/2006, Greg wrote:
>As you know, Fileman does not require that the .01 field be a key
>(meanining it is non-null and no two records can have the same value).
>This can make pointer resolution unreliable. Now, this may not even be
>a good idea, but I've often considere designing my files so that the
>.01 field is a key. What do you think about this? Is there a down side
>to making it a key? If it is made a key, what do you think about making
>the "B" cross-reference a uniqueness index? I think I once created a
>separate uniqueness index ("BB"), but then thought that doing so was
>absurd, as it would simply duplicate the "B" index, so I dweleted both
>and created a new uniqueness index ("B") and used it to support a key
>consisting of just the .01 field. Everything seemed to work fine, but I
>don't think I ever actually released any code that used a file designed
>this way.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
