DWUTKA at marlow.com
DWUTKA at marlow.com
Tue Aug 10 16:00:36 CDT 2004
Wouldn't blame you for being a 'nasty' client. In fact, you'd be thanked for being a well informed client. Can't count the number of 'clients' I've had who not only didn't know what they wanted, but didn't know what they were currently doing anyways.......go figure! Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Roz Clarke Sent: Monday, August 09, 2004 10:58 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Names or numbers? Thanks to everyone who responded. Seems I threw a stone in the pond. :) I guess I should have explained the situation more clearly (I was in a bit of a rush). The 'details' are both objects and rows in a table. They are objects as far as the front end is concerned but generated on the fly according to definitions held in a table. They are part of a 3rd party system which is written in Informix and over which I have no back-end control. The table is set up as follows: CODE TEXT DATE MARKER VALUE MANDATORY Y/N ...and with a few other bits of info. There is no facility to autonumber the 'details' although the code does have to be unique. When creating a new code you can see the existing codes so you could potentially just pick the next number. I can see the point about autonumber PKs and yes, strictly speaking the code field is the PK on this table. My usual approach, when creating a lookup for example, is that I would use an autonumber, plus a 'friendly' code, plus the full description. When creating joins you can use the autonumber, when running reports & so forth (we run an awful lot of one-off reports) you can use the friendly code. I take the point about not stuffing a load of information into a single code, and would ideally set up several category columns. Unfortunately I don't have the option. The real problem is that anyone developing in this system has to work with the codes. There are several places in the bespoke development environment where you can see the code but not the description. We have inherited a mixture of meaningful codes and numeric codes from earlier development projects and we find the numeric ones almost impossible to remember, thus slowing us down while we go hunt out the correct code. There are several thousand 'details' in the system. Anyway, having read all your input and discussed this with my team I decided to impose my world view on the contractor >.< I hope y'all won't hate me for being one of those nasty clients :( Roz -----Original Message----- From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] Sent: 04 August 2004 19:01 To: accessd at databaseadvisors.com Subject: RE: [AccessD] Names or numbers? What do you mean by 'details'? If you are referring to data within the tables, then you should really split things into separate fields. If a record is for a 'current phase' of development, then you create a phase of development field. If you are talking about object names.....I would go with your approach. My personal opinion of naming conventions is that you should use what makes sense to you, and the system you are working on. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Roz Clarke Sent: Wednesday, August 04, 2004 7:51 AM To: AccessD (AccessD at databaseadvisors.com) Subject: [AccessD] Names or numbers? << File: ATT04991.txt >> << File: ATT04992.txt >> Dear all I am currently engaged in an argument with a contractor over the naming of details in our database. His argument is that since the actual names of the details will never be exposed to the ordinary user, we should just give them numbers; X0000001, X0000002 and so forth. X denotes the current phase of development, another whacky idea of his. The 'friendly' names are held in a lookup table. Personally, since I have to work with these details on a daily basis, I would like the code to be a combination of categorisation, e.g. using the 1st two characters to describe the position / type of the detail, say XC for claimant details and XD for defendant details and XA for admin details, whilst using the other (up to 6) characters to describe the detail, say XCDOB for claimant's date of birth. The contractor's contention is that people will make up arbitrary & meaningless character codes which will be confusing, whereas the numbered details will be in a sensible sequence. a) he is not proposing to leave any gaps in the sequence for later insertion of related details b) I don't see how a number is going to be less confusing than an alpha code c) we can still use the lookup table with the alpha codes if needed Has anyone got any thoughts on naming conventions? Any experience of fully numeric naming systems that they can share? I have the authority to overrule him but this is a really big project so I want to get it right, and he is (theoretically) a lot more experienced than I am. He just hasn't come up with any convincing arguments. TIA Roz -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com