Try using an UPDATE JOIN of the table against itself
UPDATE
animal_table A
INNER JOIN
(
SELECT
category_id,summary_id,
animal_nbr,animal_amount,'00' info3
FROM animal_table
WHERE animal_type = 'special'
) B USING (category_id,summary_id)
SET
A.animal_info1 = B.animal_nbr,
A.animal_info2 = B.animal_amount,
A.animal_info3 = B.info3
WHERE
A.animal_type = 'cats' AND
A.category_id = 'foo';
Make sure that animal_table has a compound index on category_id and summary_id. If you do not have such an index, please run this:
ALTER TABLE animal_table ADD INDEX (category_id,summary_id);
UPDATE 2011-09-27 13:10 EDT
I just noticed that categrory_id 'foo' limits the dataset. Here is an updated refactoring of my answer ( I moved category_id = foo into the subquery )
UPDATE
animal_table A
INNER JOIN
(
SELECT
category_id,summary_id,
animal_nbr,animal_amount,'00' info3
FROM animal_table
WHERE animal_type = 'special'
AND category_id = 'foo'
) B USING (category_id,summary_id)
SET
A.animal_info1 = B.animal_nbr,
A.animal_info2 = B.animal_amount,
A.animal_info3 = B.info3
WHERE
A.animal_type = 'cats';
I also recommend adding this additional index to accommodate the subquery
ALTER TABLE animal_table ADD INDEX (animal_type,category_id);
@Chris Aldrich has given a good explanation. I will just add a few things here.
1) There is no concept of a "database user" in DB2. All authentication happens outside the database or instance, in the operating system. Also, there is no direct relationship between a user ID and a schema name, unlike in Oracle. In DB2 a schema is just a logical grouping of objects, it does not have any special security features. Any user can create any schema. For example, while logged in as mustaccio I run the statement create table foo (id int...)
, and that creates a schema MUSTACCIO (if it's not already there) and a table in it. As you see, the schema name resolution defaults to my authorization ID. However, I might as well run the statement create table alok.foo (id char(3)...)
, which in this case creates a schema ALOK and the table in it. mustaccio will be the owner of both tables.
2) Regarding the user ID mapping, I would probably say that the DAS owner dasusr1 and the fenced user db2fenc1 do not map to anything in an Oracle database. The instance owner db2inst1 maps to the oracle user ID. Whoever creates a database (might be db2inst1 or some other user authorized to do that by membership in the SYSADM group, for example) obtains DBADM and SECADM privileges in that database, which is somewhat similar to being system and/or sys (I'm not really sure what is the distinction between the two in an Oracle database). If you need a functional ID that owns database objects, you create appowner in the operating system, grant to it appropriate permissions, and connect to that user when creating objects. Similarly, you create appuser in the operating system, grant object access privileges to it, and let your application connect as that user.
3) Since there are no database users in DB2, you cannot drop a user. To delete objects in a particular schema you can use the ADMIN_DROP_SCHEMA() procedure.
Best Answer
There is not. Unless (until) one develops it (MySQL is open-source, anyone can contribute.)
The ANSI/ISO SQL
WITH
keyword is used to define Common Table Expressions (CTEs) and it simplifies complex queries with one or several nested references. It's available in Oracle, Postgres, SQL-Server, DB2 but not in MySQL.The final query may have references (usually in the
FROM
clause but they could be in any other part) to anyone of the common table expressions, one or more times. The query can be written (without CTEs) in MySQL using derived tables but the references have to be made repeatedly.Example of a silly query showing all persons born in the 50s and in the month of July and the number of all persons born in the same year:
In MySQL, it could be written as:
Notice the duplication of code for the derived table
a
. In more complex queries, code would have to be written multiple times.