Comments 36
хм, пока интересует только один вопрос: будет ли реализовано каскадное удаление внутри одной таблицы?
А что имеется в виду под каскадным удалением внутри одной таблицы?
Что-то типа этого:
mysql> drop table t3;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE TABLE `t3` ( `i3` int(11) not null primary key, `j3` int(11) not null, foreign key(j3) references t3(i3) on delete cascade) engine=innodb;
Query OK, 0 rows affected (0.11 sec)
mysql> insert into t3 values(1,1),(2,2),(3,3),(4,1);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> select * from t3;
+----+----+
| i3 | j3 |
+----+----+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 1 |
+----+----+
4 rows in set (0.00 sec)
mysql> delete from t3 where i3=1;
Query OK, 1 row affected (0.00 sec)
mysql> select * from t3;
+----+----+
| i3 | j3 |
+----+----+
| 2 | 2 |
| 3 | 3 |
+----+----+
2 rows in set (0.00 sec)
Что-то типа этого:
mysql> drop table t3;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE TABLE `t3` ( `i3` int(11) not null primary key, `j3` int(11) not null, foreign key(j3) references t3(i3) on delete cascade) engine=innodb;
Query OK, 0 rows affected (0.11 sec)
mysql> insert into t3 values(1,1),(2,2),(3,3),(4,1);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> select * from t3;
+----+----+
| i3 | j3 |
+----+----+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 1 |
+----+----+
4 rows in set (0.00 sec)
mysql> delete from t3 where i3=1;
Query OK, 1 row affected (0.00 sec)
mysql> select * from t3;
+----+----+
| i3 | j3 |
+----+----+
| 2 | 2 |
| 3 | 3 |
+----+----+
2 rows in set (0.00 sec)
"P.S. Чур вопрос - когда MySQL кластер будет работать с HDD не предлагать ;-)"
Так давно уж работает =)
Так давно уж работает =)
Когда MySQL начнет нормально оптимизировать и отрабатывать запросы типа
select t1.value, t2.value from table1 as t1
left join table2 t2 on (t1.id = t2.id)
where t1.value like '%value%' OR t2.value like '%value%'
а так же во всех остальных случаях когда по OR ищется в 2 и более связанных таблицах
select t1.value, t2.value from table1 as t1
left join table2 t2 on (t1.id = t2.id)
where t1.value like '%value%' OR t2.value like '%value%'
а так же во всех остальных случаях когда по OR ищется в 2 и более связанных таблицах
Когда появится такой тип данных, как массивы. Когда сделают возможным использование php для написания сторед процедур и ф-ций
1) будет ли возможность использовать вложенные запросы? А то workaround с derived неэстетично.
2) а всёж таки почему второй BEGIN выполняет на самом деле COMMIT; BEGIN; ? Эта "недокументированная фича" на мой взгляд крайне не логична, ибо ежели уж не поддерживаются вложенные транзакции, то почему бы просто не игнорировать второй BEGIN; ?
2) а всёж таки почему второй BEGIN выполняет на самом деле COMMIT; BEGIN; ? Эта "недокументированная фича" на мой взгляд крайне не логична, ибо ежели уж не поддерживаются вложенные транзакции, то почему бы просто не игнорировать второй BEGIN; ?
>> 1) будет ли возможность использовать вложенные запросы?
- а по моему можно использовать вложенные запросы... или я что-то перепутал?
- а по моему можно использовать вложенные запросы... или я что-то перепутал?
А Вы пробовали делать это хоть на каких-нибудь разумных объёмах? Просто mysql обрабатывает конструкции типа where id in (select id from blablabla) крайне неразумно.
да, согласен, медленно и неразумно, но это уже вопрос об оптимизации работы, а не о возможности использования.
Я вообще стараюсь избегать вложеных запросов, хотя иногда они очень помогают
Я вообще стараюсь избегать вложеных запросов, хотя иногда они очень помогают
что для вас разумные объёмы????
Обещают оптимизировать подзапросы в 6.0. http://dev.mysql.com/doc/refman/6.0/en/m…
а вы не пробовали использовать джойн? ;-)
Будет ли поддержка каскадного удаления ?
Появится ли поддержка ролей (либо групп пользователей) в обозримом будущем ?
Когда исправят баг с невыполнением триггеров при каскадном удалении, багрепорт датирован 21 Jun 2005 2:08, а воз и ныне там.
(ссылка на багтрек)
(ссылка на багтрек)
1. Когда появится FULL JOIN? А то приходится жонглировать LEFT/RIGHT JOIN.
2. Когда нормально заработает GROUP BY id DESC? Поясню. GROUP BY группирует схожие записи, выбирая первую строчку из группы забивая на остальные. Из опыта скажу, что есть необходимость, сгрупировав, выводить последнюю из группы. Казалось бы для этого есть GROUP BY id DESC, но GROUP BY id DESC = GROUP BY id ORDER BY id DESC , что всё равно выводит первую строчку из группы и отсортировывает их...
Приходится использовать медленную констукцию:
SELECT id, type, data
FROM table
WHERE id IN (SELECT MAX(id) FROM table GROUP BY type)
3. Что-нибудь делается для ускорения JOIN?
4. Будет ли возможность шифровать БД? Если файлы MySQL сольют, то вытащить оттуда не составляет труда, имхо.
2. Когда нормально заработает GROUP BY id DESC? Поясню. GROUP BY группирует схожие записи, выбирая первую строчку из группы забивая на остальные. Из опыта скажу, что есть необходимость, сгрупировав, выводить последнюю из группы. Казалось бы для этого есть GROUP BY id DESC, но GROUP BY id DESC = GROUP BY id ORDER BY id DESC , что всё равно выводит первую строчку из группы и отсортировывает их...
Приходится использовать медленную констукцию:
SELECT id, type, data
FROM table
WHERE id IN (SELECT MAX(id) FROM table GROUP BY type)
3. Что-нибудь делается для ускорения JOIN?
4. Будет ли возможность шифровать БД? Если файлы MySQL сольют, то вытащить оттуда не составляет труда, имхо.
4. Будет ли возможность шифровать БД? Если файлы MySQL сольют, то вытащить оттуда не составляет труда, имхо.
Имеется ввиду вытащить информацию из файлов БД
Имеется ввиду вытащить информацию из файлов БД
храните файлы на криптованном разделе (gbde, geli и т.д). на проихводительность не жалуйтесь.
в том, что кто-то когда-либо придумает способ шифрования, скрывающий данные но сохраняющий их связность (т.е. индексы), я сомневаюсь - это явно противоречивые требования просто с точки зрения банальной эрудиции=)
в том, что кто-то когда-либо придумает способ шифрования, скрывающий данные но сохраняющий их связность (т.е. индексы), я сомневаюсь - это явно противоречивые требования просто с точки зрения банальной эрудиции=)
И ещё вопрос: планируется ли ускорять работу с VIEW? Сейчас выполнение запросов напрямую без использования представлений во много раз быстрее чем с их использованием
1. Будет ли возможно использовать RETURN в хранимых процедурах? Иногда код со множеством IF-THEN-ELSE выглядит слишком громоздко.
2. Возможно ли реализовать кэширование запросов, в которых происходит обращение к UDF, при условии что она имеет характеристику DETERMINISTIC?
2. Возможно ли реализовать кэширование запросов, в которых происходит обращение к UDF, при условии что она имеет характеристику DETERMINISTIC?
Заканчиваем собирать вопросы.. до PHPConf - 2 недели
будет ли возможность использовать INSERT DELAYED с сегментированными (partitioned) таблицами?
Хотелось бы увидеть лучшей способ поиска по тексту чем тот фултекст что есть сейчас.
И систему плагинов чтоб Sphinx, например, можно было б более удобно установить.
И систему плагинов чтоб Sphinx, например, можно было б более удобно установить.
Программа конференции PHPCONF 2009
http://phpconf.ru/
ФОРМАТ:
В 2009 году мы еще более жестко отфильтровываем доклады и допускаем на конференцию только самое ценное и самое важное. Мы ценим время участников конференции, поэтому конференция по прежнему будет проходить в течении двух дней.
День первый – WebArchitect WorkShop Day 8 октября (чт)
Это день полностью состоящий из мастер-классов. Их прочитают признанные гуру. Каждый мастер-класс могут посетить не более 30 человек. На данный момент планируется 3 потока по 6 часов. Каждый мастер-класс длительностью от 1,5 до 6 часов.
День второй – PHPCONF 2009 9 октября (пт)
Пополните ваши знания! Что нового произошло за 1,5 года? Какие методики разработки стали общепринятыми в профессиональной среде? Как их внедрить малой кровью? Как повысить эффективность вашей работы и работы вашей команды в разы?
P.S. Как всегда приедут непосредственный авторы PHP, MySQL, ZendFramework.
P.S.S. Программа будет опубликована после 25 августа 2009 года.
Регистрация PHPCONF 2009 уже открыта!
http://phpconf.ru/
ФОРМАТ:
В 2009 году мы еще более жестко отфильтровываем доклады и допускаем на конференцию только самое ценное и самое важное. Мы ценим время участников конференции, поэтому конференция по прежнему будет проходить в течении двух дней.
День первый – WebArchitect WorkShop Day 8 октября (чт)
Это день полностью состоящий из мастер-классов. Их прочитают признанные гуру. Каждый мастер-класс могут посетить не более 30 человек. На данный момент планируется 3 потока по 6 часов. Каждый мастер-класс длительностью от 1,5 до 6 часов.
День второй – PHPCONF 2009 9 октября (пт)
Пополните ваши знания! Что нового произошло за 1,5 года? Какие методики разработки стали общепринятыми в профессиональной среде? Как их внедрить малой кровью? Как повысить эффективность вашей работы и работы вашей команды в разы?
P.S. Как всегда приедут непосредственный авторы PHP, MySQL, ZendFramework.
P.S.S. Программа будет опубликована после 25 августа 2009 года.
Регистрация PHPCONF 2009 уже открыта!
Sign up to leave a comment.
Вопросы авторам MySQL на PHPConf 2008 29-30мая в Москве