[Лысый]

chaynik:

Natural join - ето обычные INNER JOIN, т.е. тот пример который и я и я Junkers привели. Разница в том, что его пример называется "старым" стандартом и ето единственый join, который поддерживает SQL-92 где соединение уточняется (specified) в "WHERE clause" (не знаю как "clause" по русски).

Ну не совсем так... "Естественное(natural) соединение определяется в стандарте как эквисоединение двух таблиц, автоматически выполняемое по всем столбцам с одинаковыми именами." М.Грабер
Пример:

SELECT a.ddd, b.fff
  FROM table1 a NATURAL JOIN table2 b;

Связь осуществляется по полям с одинаковыми именами. Хотя это всего лишь договоренность...

Ну, а в specified явным образом указывается как д. происходить соединение. Другими словами связывание по where никто не отменял. А в стандарте просто определены операторы, облегчающие выполнение некоторых распространенных операций соединения (ON, USING, UNION JOIN). Связывание ч/з "on" предпочтительнее чем ч/з "where" для оптимизатора при построении плана запроса.

Так что приведенные вами запросы используют явное соединение. И связывание, которое привел Junkers вполне корректно.

Лысый добавил [date]1111561309[/date]:

(не знаю как "clause" по русски).

Я думаю - предложение.

[Alkeeper]

На mysql.net лежит дока к самой последней 5-й версии alpha, которая поддерживает и foreign key и вложенные запросы типа:
SELECT * FROM `tab` WHERE `item` IN (SELECT * FROM `another_tab` WHERE ...);

Проблема вся в том, что 5-я версия нигде не стоит, максимум - 4-я, которая ни того, ни другого не поддерживает.

Так что пользуйте товарищи PostgreSQL, там есть и то и другое!

[Лысый]

Alkeeper:
Проблема вся в том, что 5-я версия нигде не стоит, максимум - 4-я, которая ни того, ни другого не поддерживает.

Так что пользуйте товарищи PostgreSQL, там есть и то и другое!

Да, 5-ой пока не пахнет у провайдеров. У нас правда и PostgreSQL нет у местных провов...


Злая у тебя подпись...

[chaynik]

Alkeeper:
На mysql.net лежит дока к самой последней 5-й версии alpha, которая поддерживает и foreign key и вложенные запросы типа:
SELECT * FROM `tab` WHERE `item` IN (SELECT * FROM `another_tab` WHERE ...);

Проблема вся в том, что 5-я версия нигде не стоит, максимум - 4-я, которая ни того, ни другого не поддерживает.

Так что пользуйте товарищи PostgreSQL, там есть и то и другое!

Когда я подключаюсь к нашему MySQL серверу то выдается инфа, что установлена версия 4.0.18-Max

Так вот, когда добавил FK constraint с помошью вышеприведённого примера, то сервер никакой ошибки не выдал. Означает ли ето, что скрипт поддерживается?

Где можно разузнать побольше про PostgreSQL?

[Лысый]

chaynik:
Когда я подключаюсь к нашему MySQL серверу то выдается инфа, что установлена версия 4.0.18-Max

Так вот, когда добавил FK constraint с помошью вышеприведённого примера, то сервер никакой ошибки не выдал. Означает ли ето, что скрипт поддерживается?

А ты попробуй ввести не корректные данные, нарушь ограничение FK и все станет ясно...

[chaynik]

Лысый:
Так что приведенные вами запросы используют явное соединение. И связывание, которое привел Junkers вполне корректно.

Ну я же не сказал, что он не корректен.

Просто соединение в "WHERE" было стандартом в SQL-89, который позаимствовал и новый SQL-92 стандарт, поетому такое соединение иногда называется "старым" стандартом, хотя прекрасно поддерживается новым стандартом.

[Alkeeper]

http://www.postgresql.org/
На http://linux.ru/ кажется что-то было.

Вот еще:
http://phppgadmin.sourceforge.net/ - приблуда типа phpmyadmin
http://linux.shadrinsk.net/opennet/d...min/admin.html
http://www.hardline.ru/2/21/1126/
http://php.russofile.ru/pg_8_transactions.html
http://www.ru.postgresql.org/

[Лысый]

chaynik:
Ну я же не сказал, что он не корректен.

Просто соединение в "WHERE" было стандартом в SQL-89, который позаимствовал и новый SQL-92 стандарт, поетому такое соединение иногда называется "старым" стандартом, хотя прекрасно поддерживается новым стандартом.

Хорошо с оговоркой "иногда" я согласен...

[chaynik]

Alkeeper:
MySQL не поддерживает foreign_key

Лысый:

А ты попробуй ввести не корректные данные, нарушь ограничение FK и все станет ясно...

Короче, сбили с толку меня ети заявления. Ну не может быть чтобы MySQL неподдерживал Foreign Key, хотя я только начал знакомство с етой DBMS.

Короче вот, что наковырял в mysql.com:

1.7.5.5. Foreign Keys

In MySQL Server 3.23.44 and up, the InnoDB storage engine supports checking of foreign key constraints, including CASCADE, ON DELETE, and ON UPDATE. See Section 15.7.4, “FOREIGN KEY Constraints”.

Link:
http://dev.mysql.com/doc/mysql/en/ansi-diff-foreign-keys.html

Значит здесь идёт речь о версии 3.23.44 и выше. А у провайдеров какая стоит? Правильно 4-ая и выше.

На том же сайте ишем дальше:

15.7.4. FOREIGN KEY Constraints

Starting from MySQL 3.23.44, InnoDB features foreign key constraints.

The syntax of a foreign key constraint definition in InnoDB looks like this:

[CONSTRAINT symbol] FOREIGN KEY [id] (index_col_name, ...)
REFERENCES tbl_name (index_col_name, ...)
[ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT}]
[ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT}]

УАУ, узнаём, что также поддерживается cascade update and delete. Ну прям SQL Server.

Остается выяснить, что же такое за зверь такой етот INNO_DB и как его создать:

CREATE TABLE parent(id INT NOT NULL,
PRIMARY KEY (id)
) TYPE=INNODB;
CREATE TABLE child(id INT, parent_id INT,
INDEX par_ind (parent_id),
FOREIGN KEY (parent_id) REFERENCES parent(id)
ON DELETE CASCADE
) TYPE=INNODB;

Вот и всё. Теперь создание Foreign Key constraints будет поддерживатся как и должно быть в любом уважающем себя DBMS.

ps. все цитаты взяты из оффициального сайта разработчиков MySQL

[Лысый]

А кто спорит с INNODB так и есть. Мы же тебе про умолчательный тип myisam говорили.