Hi Chris, Geof, everybody...
Here's a contribution on attributes best practices:
The best way to handle attributes is to group them by domain. A common example of an attribute domain is the "money" data type, which is provided by several RDBMS products: it is a real number, with a so-many decimal places (usually four, but for most operations two is OK).
(Chris, be patient with me: I'll will get to deal with the point you have raised.)
Unfortunately, RDBMS do not readily provide us with "weight", "rate", "person_name", "country_name", "integer_key", "small_key", and other data domains we would just love to have. Yes, of course, RDBMS provide us with user-defined data types; but you still have to do some analysis in order to define your user-defined data types. For example, you have to arrive at something like the following (I'm using Transact-SQL):
sp_addtype dt_int_key,int
sp_addtype dt_name,'varchar(50)'
sp_addtype dt_address_lin1,'varchar(70)'
sp_addtype dt_description,'varchar(70)'
sp_addtype dt_rate,'numeric(12,6)'
and so forth...
If we could have a good data domain hierarchy, which would be supported by data domains in EA, we could make everybody's work more productive. Imagine: we wouldn't have to cope with a first_name being a char of... mmm... (how many?)
A great percentage (I'd say above 90%) of attributes could be assigned by EA users to a data domain type. Variables would (and at least in SQL code they should) be assigned according to these domains; for example:
DECLARE @last_key_assigned dt_int_key,
@object_name dt_name,
@currency_key dt_small_key,
@LCy_in_USD dt_rate
@currency_name dt_name
Of course, the usual data types for each RDBMS should still be available, because you do have cases you have to add in the last minute.
An additional nicety could be achieved by having the SQL to generate the corresponding user-defined data types downloaded from EA's profiles in Sparx's web page (and extended or improved domains could be produced by EA's partners)... or, there could be facility in EA to generate code for domain data types.
Ideally, if you can have 100% of your attributes assigned to data domains, your model would work pretty well with a variety of RDBMS products.
In a week or so I will send Sparx, by EMail, the data type hierarchy I've used successfully in my projects. Sparx can criticize it, improve it, publish it in EA's web page, trash it, whatever..., with the idea of having a departure point which can be enriched by other EA users so as to serve at least for vanilla-flavor projects.
Once we have a good hierarchy, and good default values for each domain, Sparx can incorporate data domains in the default EA project, and we could also incorporate them into existing projects through some import process.
EA could provide a dialog (say, extended data domain definitions through Reference -> Data domains) to define the default tag values that Chris wants. Through this dialog a user could make some modifications to existing domains (but not change data type or length), or could add new domains (such as "large_last_name", or "bigint_key"), as needed.
It sounds almost incredible that --in the age of computers-- we are currently working like 18th century artisans, painfully adjusting every little piece we make, when we should be assembling from standard elements.
Jaime Gonzalez
