This obviously doesn’t exactly answer your question, but I would think
you would want a table like this
id integer auto_increment primary key
id_value integer not null (name it whatever you want, it corresponds to
the user-specified id value in your table
word varchar(40)
The id column is rails is meant to be an auto-increment value with no
meaning within your problem space.
What benefits do you feel your scheme has over this one?
On Wed, Dec 28, 2005 at 02:18:03PM -0500, Mike H. wrote:
Radek Hnilica wrote:
This obviously doesn’t exactly answer your question, but I would think
you would want a table like this
id integer auto_increment primary key
id_value integer not null (name it whatever you want, it corresponds to
the user-specified id value in your table
word varchar(40)
I do not underestand what you mean. Your model doesnt fit the
constraints. Did you mean something like I’m experimenting now with:
CREATE TABLE employees (
id SERIAL PRIMARY KEY,
pin INTEGER UNIQUE, – worker personal identification
first_name VARCHAR(30) NOT NULL,
last_name VARCHAR(30) NOT NULL
);
Where the pin is unique identification which is assigned to each
employee and newer change. It has nothing to do with ATM or
passwords. It’s the same if the employee leave our firma and later
get on. His name can change, but his pin not.
The id column is rails is meant to be an auto-increment value with no
meaning within your problem space.
What benefits do you feel your scheme has over this one?
I’m not sure, there are many unresolved things yet. For instance:
Which fields (columns) can be in relations has_many, belongs_to.
What restrictions I can place on database model to not bother the
rails. What I mean. In the related table, say
CREATE TABLE some_record_headers (
id SERIAL PRIMARY KEY,
worker_id INTEGER NOT NULL REFERENCES employees(pin),
relay_number INTEGER NOT NULL,
…
);
In such table what field I have te REFERENCE, the natural key or the
synthetic key.
How do other people underestand the data model. The people
accessing the database through another tools, completly unrelated to
Rails or Ruby. In mine example, another worker will connect to
database to read some_record_headers and some_record_items. He is
completly uninterested in workers name or some synthetic id, but he
need to know the workers pin.
What about some task and processes I need to implement as a
standalone programs, processing the database and do its own things.
Sometimes it can be only one or few tables in which in need to use my
own natural key instead of synthetic. In many cases I can live with
numeric keys and the records need only be created. The key will never
changes.