March 12, 2002 at 7:50 am
I'm currently mapping our Clipper dbfs to a relational database (MSSQL of course). While we wont be starting with a completely clean slate I would like to ensure that we use as much of the SQL database functionality as possible. I plan to make use of udt's but am not sure exactly where I should draw the line?
For instance - we have a number of 'code' type fields in the dbfs which range in size from 3 to 10 (eg clientcode is 6 chars and is used in about 30 places; invcode is 3 chars and is used in about 12 places). I could go and create a separate data type for each code or I could create a generic code type that is of varchar(10) to cater for all codes types. Is this good or bad practice?
Also if I follow this pattern then surely every variable character field that I have I should merely use a udt varchar field that caters for all sizes?
any comments appreciated.
March 12, 2002 at 11:30 am
I'd say one generic 'code' data type is a good idea. I don't use udt's often, but lately Im doing more maintenance work than new design so maybe that's why! I don't see any reason not to use them.
Andy
March 12, 2002 at 11:56 am
I don't really use them. Never saw a great use. If you have control of the db, then you know what the data is. If there are more people doing development, it's one more thing you have to go behind them an verify.
I'd avoid them, but that's my pref.
Steve Jones
March 12, 2002 at 12:36 pm
I generally have had few needs for UDF, they should be used as a last resort if you can find another method (one the does not include cursors). If you cannot do it with anything predefined or in a stored procedure then go UDF. You also should not think in terms of limits just terms of efficient.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply