PDA

View Full Version : Newbie: 'id' fields in data stores



n4hpg
6 May 2010, 8:26 AM
Having "read the fine manuals" - those from PACKT publishing, this question is regarding what may be contained in the 'id' fields of the data stores. Please forgive me as I'm presently converting from ActiveWidgets...

All of the example 'id' fields in the data stores are simple integers in the examples such as

[0,'some data'],
[1,'more data'],
[2,'yet more data']

1. Does ExtJS use these as the controlling index value?
2. Must it always be an integer?

The record IDs in my database are string. Some examples would be

038256
038256.1
038256.1.25
SMNC0.1

Thus, one would consider an array of:
['SMNC0.1','Medicare of North Carolina'],
['SKNC0.1','Medicaid of North Carolina'],
['SB810.1.5','Blue Cross of North Carolina']

In a grid control, I would want these record ID fields to be displayed as column data and returned during a click event. If this method is not possible, then I would presume that I should use an index value like the examples and make my record keys a column in the grid thusly:

[0,'SMNC0.1','Medicare of North Carolina'],
[1,'SKNC0.1','Medicaid of North Carolina'],
[2,'SB810.1.5','Blue Cross of North Carolina']

In this case, the onclick event would need to read from the 2nd column to return the string value as part of the posting back to the server for selection.

As always, I appreciate the help of those in the support forums who know much more than I do about this!

Bill

evant
6 May 2010, 8:37 AM
The ids dont need to be numbers, however it's often the case that it's just an auto-increment number from a database, which is why most of the examples use them. But no, the id isn't used for indexing, just a unique identifier for the record.

Mike Robinson
7 May 2010, 6:56 AM
Remember, though, that if the record is one that you've created on the client-side and not yet submitted to the host, it will have a "phantom" ID.

As a general database-design principle, I never use "human" identifiers as "database" primary-keys. An invoice or a part or a widget might have "a number," but that's not the primary-key value that I use ... because: "constants aren't, and variables don't."

I learned this lesson while re-engineering an application for a health care company that had encoded information into its "provider id's," in what was originally a human-managed system with a much smaller number of providers. Over the years, multiple IDs had been assigned to the same provider, and the same ID had been assigned to multiple providers, and the original database couldn't handle that. Since I knew that the database records would have a long life, I built the system to use an early poor-man's version of what's now known as a UUID-string. The primary key was absolutely random, human-readable but perfectly meaningless. All of the "human" identifiers, ambiguous or not, were first translated to an unambiguous primary-key that was known only to the computer.

Eventually, of course, they wanted to use those identifiers. Instead, I built the system to automatically coin another string that they could safely use. Thus, the relationship between two disparate systems was "present, but not 'joined at the hip.' " It worked fine.