I reformulate my needs. How I can write (layout/controller) so I can read value of Id from the new form when creating new record. With following structure: CREATE TABLE words ( id INTEGER PRIMARY KEY, word VARCHAR(40) ); I want enter new records like: id=47812, word='pes' id=1382, word='krough' id=67145, word='brum' -- Radek
on 2005-12-28 11:46
on 2005-12-28 20:19
Radek Hnilica wrote: >id=47812, word='pes' >id=1382, word='krough' >id=67145, word='brum' > >-- Radek > > > 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 2005-12-28 22:14
On Wed, Dec 28, 2005 at 02:18:03PM -0500, Mike Harris 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: 1. 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. 2. 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. 3. 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. -- Radek Hnilica <Radek at Hnilica dot CZ> http://www.hnilica.cz ============================================================== No matter how far down the wrong road you've gone, turn back. Turkish proverb ... so turn back ... Now!