Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 16 of 16 total |
It's possible rename RecordID field in tables? |
Fri, Jan 20 2006 10:30 AM | Permanent Link |
Sean McCall | Greg,
Actually I don't use field names like that, but I can see how RecordID would be a likely candidate for a primary key field name in a table. This could be an issue for someone converting an application from another database system. I do, however, strongly believe in a using single unique record identifer since it allows for single field foreign keys which in turn makes lookups very easy to manage. I actually take it a step further and use long integer "serial numbers" for my records that encode both a table-unique sequence number and a table-specific identifer. (Example: Table ID = 27, Record Sequence = 37 ==> Serial Number = 370027). This way, I can have have tables with database-wide reference fields and just by examining the serial number I can determine both the table and the record for drilling down. In addition, I can detect table corruption if a record serial number does not conform to the encoding rules for its table. Take it easy, Sean GregF wrote: > "Ralf Mimoun" <nospam@rad-on.de> wrote in message news:4DC87D75-78FD-4AD3-865C-462EB3342CF9@news.elevatesoft.com... > >>Sean McCall wrote: >> >>>Tim, >>> >>>Maybe it would make sense to use field names unlikely to >>>cause a conflict in version 5 like and just leave them as >>>constants: >> >>Many developers are using the new field names. I don't think that it's a good idea to break their code just to satisfy one user - >>sorry. I don't even think that's it a good idea to make the field names changeable as properties. Some metastructures should be >>hard to change. >> >>Ralf >> >> > > > I think that Sean is mostly right > Tim needs to use less "generic" field names > but at the same time Sean also needs to use > less generic field names. > > I stay far far away from using generic terms > and always use specific names > > However I am ambivalent over the use of any field called RecordID > as an old data analyst I would maintain that every record > should be unique and if the fields within the table > can't make it so then you need to re-assess the table structure > > gregF > > |
Fri, Jan 20 2006 10:46 AM | Permanent Link |
Sean McCall | Oops... make that a <large integer> serial number
Sean Sean McCall wrote: > Greg, > > Actually I don't use field names like that, but I can see how RecordID > would be a likely candidate for a primary key field name in a table. > This could be an issue for someone converting an application from > another database system. > > I do, however, strongly believe in a using single unique record > identifer since it allows for single field foreign keys which in turn > makes lookups very easy to manage. I actually take it a step further and > use long integer "serial numbers" for my records that encode both a > table-unique sequence number and a table-specific identifer. (Example: > Table ID = 27, Record Sequence = 37 ==> Serial Number = 370027). This > way, I can have have tables with database-wide reference fields and just > by examining the serial number I can determine both the table and the > record for drilling down. In addition, I can detect table corruption if > a record serial number does not conform to the encoding rules for its > table. > > Take it easy, > > Sean > > GregF wrote: > >> "Ralf Mimoun" <nospam@rad-on.de> wrote in message >> news:4DC87D75-78FD-4AD3-865C-462EB3342CF9@news.elevatesoft.com... >> >>> Sean McCall wrote: >>> >>>> Tim, >>>> >>>> Maybe it would make sense to use field names unlikely to >>>> cause a conflict in version 5 like and just leave them as >>>> constants: >>> >>> >>> Many developers are using the new field names. I don't think that >>> it's a good idea to break their code just to satisfy one user - >>> sorry. I don't even think that's it a good idea to make the field >>> names changeable as properties. Some metastructures should be hard to >>> change. >>> >>> Ralf >>> >>> >> >> >> I think that Sean is mostly right >> Tim needs to use less "generic" field names >> but at the same time Sean also needs to use >> less generic field names. >> >> I stay far far away from using generic terms >> and always use specific names >> >> However I am ambivalent over the use of any field called RecordID >> as an old data analyst I would maintain that every record >> should be unique and if the fields within the table >> can't make it so then you need to re-assess the table structure >> >> gregF >> |
Fri, Jan 20 2006 4:21 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Stefano,
<< If you make them usable in the next release (Dbisam 4) I use it and the problem is solved!; >> I wish it were that easy for everyone. It's easy for us to make that change, but it would break every application that relies on the field positions being like they are now, especially for altering tables, etc. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Jan 20 2006 4:22 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Sean,
<< Maybe it would make sense to use field names unlikely to cause a conflict in version 5 like and just leave them as constants: EDB_Sys_Record_ID EDB_Sys_Record_Hash >> Actually, the hash is gone and the current name for version 5 is simply RowID. -- Tim Young Elevate Software www.elevatesoft.com |
Sun, Jan 22 2006 10:01 AM | Permanent Link |
"Stefano Monterisi" | Hi Tim,
in porting, we are working on rename our RecordID to ID; please don't change RecordID to ID, or we still to rechange names! Stefano Monterisi "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> ha scritto nel messaggio news:477C10BA-44C5-4765-A30B-EF482356A600@news.elevatesoft.com... > Stefano, > > << If you make them usable in the next release (Dbisam 4) I use it and the > problem is solved!; >> > > I wish it were that easy for everyone. It's easy for us to make that > change, but it would break every application that relies on the field > positions being like they are now, especially for altering tables, etc. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Mon, Jan 23 2006 5:14 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Stefano,
<< in porting, we are working on rename our RecordID to ID; please don't change RecordID to ID, or we still to rechange names! >> You won't find the word "Record" anywhere in ElevateDB. It is now the proper SQL term - "Row". -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |