Hi Dhanuka, Well, I believe, here there are two key concerns that need to be addressed.
1. Making names of the database entities (tables, columns, indexes, etc) intuitive. 2. Naming, constraints such as Foreign Key constrains, etc. Out of the two aforementioned aspects, 1st aspect is usually and obviously followed by everyone who's developing applications that deal with databases. To make it more intuitive, in Carbon, we usually follow this pattern where a prefix is appended to the names of database entities used with a particular Carbon component in the form of, for example, REG_*, UM_*, RM_*, etc so that people can figure out/manipulate which database entity belongs to what component and so on, without much trouble. However, when it comes to the 2nd aspect, it is certainly required that we name constraints, etc whenever possible so that it would be easier for people, particularly in terms of maintenance related tasks as you've mentioned. This is quite important particularly in the long run as usually when the schemas mature, migrations take place etc. Not only that, there are other stuff too, that we don't usually pay too much attention to, when it comes to the aspect of database maintenance and this is just one of 'em. I believe, we need to address/document all these concerns so that it will make life much easier to everybody. Having said that, IMO, all these naming stuff are usually bound to one particular condition which is the "maximum length allowed for identifiers". Things get much worse when we have to support multiple database types as generally, the values imposed upon this attribute is dependent on the database type being used. As we develop applications to be portable with other available database options too, this usually becomes a challenge and thus, it's sometimes hard to enforce any rules/standards as suggested. Therefore, my recommendation would be to name database entities as short and intuitive as possible without any unnecessary/duplicate prefixes/suffixes/etc while ensuring the schema is portable across most (at least the ones that are often used) of the database types that are available in the industry. Cheers, Prabath On Mon, Jan 20, 2014 at 1:46 PM, Dhanuka Ranasinghe <dhan...@wso2.com>wrote: > Hi All, > > Is there any $Subject . While writing some migration scripts for SS, > noticed one mistake that we have done was not mention names explicitly for > SQL indexes and constraints. Because of that we have to find out those > names when doing a modification to tables and due to that migration scripts > not become straightforward. So If we going to mention names explicitly we > should have a naming convention for that since it will make life easier for > maintenance. > > ex: When define index for foreign key we can use something like below. > > schema_db_table_fk_index_name > > Cheers, > > > *Dhanuka Ranasinghe* > > Senior Software Engineer > WSO2 Inc. ; http://wso2.com > lean . enterprise . middleware > > phone : +94 715381915 > > -- > You received this message because you are subscribed to the Google Groups > "WSO2 Engineering Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to engineering-group+unsubscr...@wso2.com. > For more options, visit > https://groups.google.com/a/wso2.com/groups/opt_out. > -- Prabath Abeysekara Associate Technical Lead, Data TG. WSO2 Inc. Email: praba...@wso2.com Mobile: +94774171471
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
