On Tue, Jan 21, 2014 at 3:16 AM, Prabath Abeysekera <[email protected]>wrote:
> 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 > and consistent too. > 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 <[email protected]>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 [email protected]. >> For more options, visit >> https://groups.google.com/a/wso2.com/groups/opt_out. >> > > > > -- > Prabath Abeysekara > Associate Technical Lead, Data TG. > WSO2 Inc. > Email: [email protected] > Mobile: +94774171471 > Cheers, Prabath -- Prabath Abeysekara Associate Technical Lead, Data TG. WSO2 Inc. Email: [email protected] Mobile: +94774171471
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
