Hi, Sanjiv I've already known Scott Ambler as 1 of the main well regarded Agile Approaches guru ! (bcoz I'm Agile defender! ;-)) Thnx so much for the link! Take it for grant: I'm gonna check it out!! :D And still in the case u metioned (changing ID), it can be "assembled" with the use of Update Cascade.(in simple DataBases as Paradox7(yeah, that 1 that is default of Delphi3, 4, 5, +; this features is present) Yeah, I know a lot of DBAs don't thrust this feature. And also a lot of people make up them Data Model in the DataBase withOut the use of ForeingKeys (if u get what I mean): Simply philosophical (conceptual) ForeingKeys; I think that's a so cacketic (obsolet/old fashion) so as define a literal field (of VarChar Type) to data like of the type DateTime. I think u have to implement a System in production, but for internal use, u could choose a DataBase product (MySQL, for instance) and adote that appoach. So, u would have just a great opportunity to prove the liability of this feature (in that product/DataBase, of course). Yeah, I think that's all! :-) See u,
Ice-Man 2008/12/17 Sanjiv Jivan <[email protected]> > "Agile Database Techniques" by Scott Ambler (well regarded DB guru) has an > excellent discussion on the key picking strategy. The short version is that > surrogate keys is most often the right strategy however there are certain > types of data that are commonly accessed by unique identifiers where use of > natural keys may be more appropriate. The User, Role tables seem to fall > under this category - unless changing usernames was a supported use case for > the application > Here is an article by him where he discusses this : > http://java.sys-con.com/node/36660 > > Sanjiv > > On Tue, Dec 16, 2008 at 9:51 AM, Ice-Man <[email protected]>wrote: > >> In the example, I mean the year of entering (starting year) College >> (instead of degree). (yeah, my english was not so good this time! :o) >> So, in the case u exposed, there is a performance >> Restriction/Requisite. (That would be a reason to change Identifying >> approach.) >> >> Ice-Man >> >> >> 2008/12/15 Nathan Anderson <[email protected]> >> >>> Iceman, >>> >>> In a perfect wolrd there would never be a need to create an artificial >>> primary key. However once people start using the applications things >>> tend to get messier. >>> >>> Using your example, what happens when the student changes majors or >>> enters a post graduate degree and his ID changes to refelct the >>> deparetment change. If you have foreign key references on that logical >>> primary key you have a problem. Even if the business logic states the >>> ID should never change, people make mistakes so you still need to be >>> able to change that field. >>> >>> There can also be a matter of performace. There is no faster index >>> than an integer. So forcing your database to use a logical primary key >>> (or composite key) can hinder database performance depending on your >>> situation. >>> >>> Nathan >>> >>> >>> On 12/15/08, Ice-Man <[email protected]> wrote: >>> > I strongly DESAGREE u. Acording Data Modeling (entity-relation >>> modeling) >>> > there isn't any reason to create an ARTIFICAL IDENTIFIER ATTRIBUTE, if >>> there >>> > is a REAL data that can be used as the identifier. >>> > Otherwise u may designate a artifical identifier. Pupils from >>> Colleges >>> > Applicants use to be an anagrama of letters and numbers (so that make >>> up >>> > ID). I think u guess what I mean. >>> > >>> > Gupta, >>> > >>> > But, I think it's almost impossible to set Hibernate to generate such >>> ID >>> > in automatic fashion. It's better to generate that ID by your >>> application >>> > and set Hibernate so that. I think that's the simplest way. >>> > Hope helping, >>> > >>> > Ice-Man >>> > >>> > 2008/12/15 Nathan Anderson <[email protected]> >>> > >>> >> Just like Oscar stated, it is generally considered a best practice to >>> have >>> >> database primary keys that have no business meaning attached to them. >>> The >>> >> example you provide appears as though it probably should be defined as >>> a >>> >> unique not null column, but not primary key. But even if you change >>> the >>> >> data structure that doesn't solve the problem of auto assigning the >>> "next" >>> >> value to a new record. >>> >> >>> >> The method I have used in the past for situations like this to have a >>> >> table >>> >> in the database that holds the "next" value. Then update the value >>> >> database >>> >> either in a transaction from your application, or in a stored >>> procedure >>> >> used >>> >> to save a new record, or with a trigger on the insert statement. >>> >> >>> >> Hope that helps, >>> >> Nathan >>> >> >>> >> >>> >> >>> >> On Sun, Dec 14, 2008 at 8:51 PM, sudhakargupta < >>> >> [email protected]> wrote: >>> >> >>> >>> >>> >>> Thanks for your reply and i need an id likes the 05-CS-123 so, i need >>> an >>> >>> auto >>> >>> generated string to increment the last number, if the client want to >>> use >>> >>> the >>> >>> assigned then how to mention in model class to assign the @Id value. >>> >>> >>> >>> >>> >>> Sudhakar >>> >>> >>> >>> >>> >>> Oscar Alvarez-2 wrote: >>> >>> > >>> >>> > Hello, >>> >>> > >>> >>> > What's the diference between autogenerated Long key and >>> autogenerated >>> >>> > String >>> >>> > key???, i mean, if the String is autogenerated, it's not better >>> >>> > solution >>> >>> a >>> >>> > Long key?, but if the String key is meaningful for the end user, >>> then >>> >>> you >>> >>> > should define assigned strategy and assign it before save. >>> >>> > >>> >>> > Best Regards >>> >>> > >>> >>> > >>> >>> > >>> >>> > 2008/12/13 sudhakargupta <[email protected]> >>> >>> > >>> >>> >> >>> >>> >> Thanks for your reply >>> >>> >> >>> >>> >> Is there any other way to use the auto generator for the string >>> in >>> >>> mysql >>> >>> >> or in any other database >>> >>> >> >>> >>> >> please suggest me for this solution.. >>> >>> >> >>> >>> >> Sudhakar.. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> mraible wrote: >>> >>> >> > >>> >>> >> > If you're going to use Strings for the primary key, you'll have >>> to >>> >>> use >>> >>> >> > a type of generator that doesn't increment. I've never done >>> this, >>> >>> >> > hopefully someone else on this list can help you. >>> >>> >> > >>> >>> >> > Matt >>> >>> >> > >>> >>> >> > On Fri, Dec 12, 2008 at 5:39 AM, sudhakargupta >>> >>> >> > <[email protected]> wrote: >>> >>> >> >> >>> >>> >> >> Hi Matt... >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> Presently i'm working with the appfuse2 struts.. In one of my >>> >>> >> >> table >>> >>> i >>> >>> >> >> need >>> >>> >> >> to use the String as a primarykey and use foreignkey relations >>> with >>> >>> >> this >>> >>> >> >> primarykey. >>> >>> >> >> >>> >>> >> >> i created a model class primary key setters/getters are >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> @Id >>> >>> >> >> private String code; >>> >>> >> >> >>> >>> >> >> private String getCode() { >>> >>> >> >> return this.code; >>> >>> >> >> } >>> >>> >> >> >>> >>> >> >> private void setCode(String code) { >>> >>> >> >> this.code = code; >>> >>> >> >> } >>> >>> >> >> >>> >>> >> >> and after that run the command like mvn appfuse:gen and creates >>> the >>> >>> >> all >>> >>> >> >> the >>> >>> >> >> action classes and the jsp files. after that run the command >>> like >>> >>> mvn >>> >>> >> >> jetty:run, then it shows the errors to create the database and >>> to >>> >>> run >>> >>> >> the >>> >>> >> >> project.. >>> >>> >> >> >>> >>> >> >> it shows the errors like primarykey field must be the Long >>> >>> datatype.. >>> >>> >> >> >>> >>> >> >> can u please suggest me to create the database through appfuse >>> .. >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> Sudhakar >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> -- >>> >>> >> >> View this message in context: >>> >>> >> >> >>> >>> >> >>> >>> >>> http://www.nabble.com/Appfuse2-Struts-problem-tp20974893s2369p20974893.html >>> >>> >> >> Sent from the AppFuse - User mailing list archive at >>> Nabble.com. >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> --------------------------------------------------------------------- >>> >>> >> >> To unsubscribe, e-mail: [email protected] >>> >>> >> >> For additional commands, e-mail: >>> [email protected] >>> >>> >> >> >>> >>> >> >> >>> >>> >> > >>> >>> >> > >>> --------------------------------------------------------------------- >>> >>> >> > To unsubscribe, e-mail: [email protected] >>> >>> >> > For additional commands, e-mail: >>> [email protected] >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> >>> >>> >> -- >>> >>> >> View this message in context: >>> >>> >> >>> >>> >>> http://www.nabble.com/Appfuse2-Struts-problem-tp20974893s2369p20988292.html >>> >>> >> Sent from the AppFuse - User mailing list archive at Nabble.com. >>> >>> >> >>> >>> >> >>> >>> >> >>> --------------------------------------------------------------------- >>> >>> >> To unsubscribe, e-mail: [email protected] >>> >>> >> For additional commands, e-mail: [email protected] >>> >>> >> >>> >>> >> >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > Atentamente >>> >>> > Oscar Alvarez V >>> >>> > (09) 8416 4052 >>> >>> > >>> >>> > >>> >>> >>> >>> -- >>> >>> View this message in context: >>> >>> >>> http://www.nabble.com/Appfuse2-Struts-problem-tp20974893s2369p21008315.html >>> >>> Sent from the AppFuse - User mailing list archive at Nabble.com. >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> >>> To unsubscribe, e-mail: [email protected] >>> >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >>> >> >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> Derlon >> >> Ao encaminhar esta mensagem (ou qualquer 1 q se destine a mim tb), não se >> esqueça de retirar o meu nome e o meu End. de E-Mail e coloque todos os >> End.s dos destinatários em Cópia Oculta - CcO (BCc). Ajude a combater o >> Spam! >> > > -- Derlon Ao encaminhar esta mensagem (ou qualquer 1 q se destine a mim tb), não se esqueça de retirar o meu nome e o meu End. de E-Mail e coloque todos os End.s dos destinatários em Cópia Oculta - CcO (BCc). Ajude a combater o Spam!
