| Subject | Re: [firebird-support] Auto Increment? |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2004-04-07T15:36:17Z |
At 03:21 AM 4/7/2004, Jason Caldwell wrote:
advantages. He mentioned that you can't get a value back from an
insert. One of MySQL's new features is a "returning" clause that can be
added to an insert, update, or delete. That's based on an ancient
InterBase feature which I described at a MySQL technical meeting last
fall. One day soon it will return to Firebird, I hope.
several indexes on a single field - should each one increment
independently? There's no reason not to introduce an auto-increment field
attribute, I suppose, as syntactic sugar.
sophisticated than what actually happens. Internally, Firebird keeps a
compiled version of the table definition. Hanging off that are compiled
versions of triggers. Using a trigger to establish a field value in a
record is as efficient, probably more efficient, than passing the value in
from your application. The cost of executing a simple trigger - something
that assigns a value to new.<field_xxx> - is no more than the cost of using
a default value. Of course triggers that lookup values from other tables
and store log records are more expensive, but still less expensive than
performing the same operations from the client.
spring. German, Japanese, Russian, and Portuguese speakers can find books
about Firebird at the IBPhoenix site.
Cheers,
Ann
>However, I do like the auto increment functionality in MySQL for PrimaryMartijn answered that part with a good description generators and their
>Key's - it seems to have this same functionality in Firebird I must create a
>Trigger with the incremental code.
advantages. He mentioned that you can't get a value back from an
insert. One of MySQL's new features is a "returning" clause that can be
added to an insert, update, or delete. That's based on an ancient
InterBase feature which I described at a MySQL technical meeting last
fall. One day soon it will return to Firebird, I hope.
>If the TriggerAuto-increment is a property of the field, not the index. You can have
>event is the way to get the auto-increments for my keys, then I would like
>to suggest for a near future release the concept of adding auto-increments
>directly by stating so in the Index, like MySQL.
several indexes on a single field - should each one increment
independently? There's no reason not to introduce an auto-increment field
attribute, I suppose, as syntactic sugar.
>I can only imagine that this would also increase Insert performance greatlyI think your mental model of triggers is a bit more complex and
>also, as the Inserts won't have to respond to trigger events.
sophisticated than what actually happens. Internally, Firebird keeps a
compiled version of the table definition. Hanging off that are compiled
versions of triggers. Using a trigger to establish a field value in a
record is as efficient, probably more efficient, than passing the value in
from your application. The cost of executing a simple trigger - something
that assigns a value to new.<field_xxx> - is no more than the cost of using
a default value. Of course triggers that lookup values from other tables
and store log records are more expensive, but still less expensive than
performing the same operations from the client.
>PS. Looking forward to learning more about FB --> btw: can anyone turn me onHelen Borrie is writing a book that should be available in the late
>to a good book or online reference material for FB --> it seems kind of hard
>to find. Thanks again.
spring. German, Japanese, Russian, and Portuguese speakers can find books
about Firebird at the IBPhoenix site.
Cheers,
Ann