rulinux.net - Форум - Talks - [n+1]А почему MySQL такое унылое гавно?

Re: [n+1]А почему MySQL такое унылое гавно?

Fri, 21 Jan 2011 00:21:13 +0300

И в Оракле тоже такой синтаксис.. Но дело даже не столько в привычке, сколько в наглядности - вставка строк всё-таки более сильное вмешательство и оно обозначается более явно когда фраза SQL начинается со слова INSERT.

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 21:10:42 +0300

> А зачем тебе так делать?

Это - общепринятая форма записи при копировании из таблицы в таблицу. Её проглотит и MySQL, и PostgreSQL:

http://dev.mysql.com/doc/refman/5.5/en/insert-select.html

http://www.postgresql.org/docs/9.0/static/sql-insert.html

(см. 6-й пример).

В то время, как SELECT INTO у разных разработчиков СУБД имеет разный смысл. Про MySQL и PostgreSQL тут уже написали, вот ещё вариант:

sql



DECLARE VARIABLE MaxId NUMERIC(16,0);

...

SELECT MAX(Id) FROM Tablename INTO :MaxId;

Это Firebird, запись результата выборки во внутреннюю переменную в хранимой процедуре.

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 15:15:18 +0300

Мечтай. А зачем тебе так делать?

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 13:47:42 +0300

Мне кажется нормальный способ вставить выборку в другую таблицу - это всё-таки "INSERT INTO tablename SELECT something FROM other table"

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 13:43:00 +0300

>Что в PostgreSQL делает SELECT INTO?
"SELECT INTO -- define a new table from the results of a query"

...skip...

Examples

Create a new table films_recent consisting of only recent entries from the table films:

SELECT * INTO films_recent FROM films WHERE date_prod >= '2002-01-01';

http://www.postgresql.org/docs/9.0/static/sql-selectinto.html

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 13:40:33 +0300

Вы, придурок? Сами c8делать не можете?

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 13:29:55 +0300

> Файл он суёт туда, где лежит БД.
по умолчанию.

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 13:18:24 +0300

Файл он суёт туда, где лежит БД.

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 13:16:27 +0300

Что в PostgreSQL делает SELECT INTO? В MySQL SELECT INTO пишет выборку в текстовый файл. Синтаксис:

sql



SELECT * INTO OUTFILE "file.txt" FROM `table`;

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 12:20:42 +0300

>Сам не пробовал и не знаю (не спец по мускулю) как это поведет себя в транзакции, но возможно твой монитор спасет:)))
Ну я примерно так и поступил:) Просто у меня был определённый database-independent файл с данными и скрипт для работы с этим форматом. По-умолчанию он такие вещи не умел, пришлось разбираться, я был сильно удивлён такому глупому поведению мускуля.

Да и вообще, костыль это, так как не проверяется валидность ключей в процессе импорта, и потом, уже в работе, может вылезти какой-нибудь integrity error. Остаётся только полагаться на идеальность и безбажность данных.

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 12:16:27 +0300

> А InnoDB не может откладывать проверки по foreign key до конца транзакции.

Сам не пробовал и не знаю (не спец по мускулю) как это поведет себя в транзакции, но возможно твой монитор спасет:)))

ALTER TABLE `data` DISABLE KEYS ALTER TABLE `data` ENABLE KEYS

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 11:57:21 +0300

Я всю прошлую неделю статистику в мускуле парсил, всего пяток миллионов строк. Сначала по-простому, по-оракловому, наджоинил несколько таблиц и сгруппировал результат чтобы посмотреть что там вообще есть, но когда наутро обнаружил что запрос продолжает крутиться, заподозрил что что-то тут не то..

Короче сложные вещи пришлось делать в не к ночи будь помянутом перлу, а для вещей попроще почму-то JOIN у них работает значительно лучше чем просто связка двух таблиц по равенству значений (видимо оптимизатор запросов там совсем никакой).

Но убить себя мне захотелось уже позже, после того как запрос вида: " SELECT start_date, end_date, end_date-start_date FROM ..." вернул вот такой вот, с позволения сказать, результат:

text



start_date             end_date              end_date-start_date

2010-12-20 05:04:47    2010-12-20 05:09:49    502.000000        

2010-12-20 05:09:49    2010-12-20 05:14:50    501.000000        

...

2010-12-20 05:39:58    2010-12-20 05:44:59    501.000000        

2010-12-20 05:44:59    2010-12-20 05:50:01    542.000000        

2010-12-20 05:50:01    2010-12-20 05:55:03    502.000000        

2010-12-20 05:55:03    2010-12-20 06:00:04    4501.000000       

2010-12-20 06:00:04    2010-12-20 06:05:06    502.000000

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 11:17:38 +0300

Поддерживаю. Это не БД, а ошибка природы. Недавно переносил один проектик с постгреса на мускуль, убил кучу времени на загрузку данных.

А почему: myisam не поддерживает транзакции, а значит не подходит сразу. А InnoDB не может откладывать проверки по foreign key до конца транзакции.

Хотелось разбить монитор.

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 11:07:11 +0300

Это ты ещё sqlite не видел...

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 11:06:24 +0300

Сравнение ни с MS SQL там тоже граблей дохренища, а PostgreSQL. Просто в сравнении с постгресом мускуль такое уебище, а в движке лоронга используется mysql\postgresql\sqlite. Со скулайтом так много проблем не возникало, во отличие от...

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 10:50:11 +0300

На фоне Оракла ненависти ещё больше..

Re: [n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 10:44:05 +0300

Сдается мне ты в администрации Cаратова занимаешься БД, причем MS SQL, иначе откуда столько ненависти ?

[n+1]А почему MySQL такое унылое гавно?

Thu, 20 Jan 2011 10:29:00 +0300

Блджад оно и SELECT INTO не умеет. Оно вообще хоть что-то умеет? Заебло. Надеюсь там с INNER JOIN граблей хотя-бы нет.