> markw@xxxxxxxxxxxxxx wrote:
>>> On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
>> There in lies the biggest problem with LAMP, and that's MySQL. The
>> architecture of your methodology *only* works with MySQL, and not more
>> capable databases like Oracle, DB2, or even PostgreSQL.
> I too thought the same thing, but was corrected when I starting working
> on a redesign for the billing system for the company that I am working
> for. They use PostgreSQL and we do have a auto incremented unique id
> field. It isn't call AUTO_INCREMENT, but rather a sequence value. It
> is a value that is controlled by the default value entry.
>
> It then runs this:
> nextval('customers_customer_id_seq'::regclass)
>
> and uses this as the value of the id field for the newly inserted row.
Yea, I've been using PG for over 10 years now. Sequences are awesome, but
there have an "auto number" column type as well. It simply creates a
sequence but it's there.
I guess maybe most databases support the notion of "auto number" in some
form. I haven't used MSSQL recently, but I think their solution is a GUID.
>
> Then instead of running a command like SELECT LAST_INSERT_ID(); you have
> to do some other stuff like this:
>
> $SQL = "SELECT currval('{$table}_{$column}_seq');";
Again, this is absolutely wrong unless it is wrapped in a transaction. You
will need a "begin" and a "commit" in an MVCC type system. If you don't
wrap it in a transaction you don't know who got the last "nextval" of the
sequence. Also, in PostgreSQL, the pre-cache sequence values for
performance. So sequences are not always sequential.
(pseudo code)
begin;
insert ... values (...);
select currval('sequence_name');
commit;
or
$foo = select nextval('user_id_sequence');
insert into users(user_id, ...) values ($foo, ...)
(Without a transaction)
Sequences are far more flexible than auto number, don't you think?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
