Лови. http://sql-info.de/mysql/gotchas.html

Для понимающих, конечно.

> тогда постгре, например, UTF-8 не знал

чё за бред? юникод в постгрес появился раньше, чем в мускле

ты часто и с жаром пишешь хорошие вещи, но в области проектирования и использования БД - прости, ты очень слаб.

ну да ты конечно силен, вылез блин, сказанул типа крутой, только база - это инструмент, а не идол и использовать её можно именно как вспомогательный инструмент, а то привыкли на ораклы молиться, а мускул им видители мордой не вышел, потому как функциональности недостаточно, тригеры им нужны и хранимые процедуры, лучше расскажи это гугловцам или кому-нибудь еще, у меня мускул из числодробильни жрет и выдает сотни тысяч строк и не пикает, зачем мне эти навороты и хранимые процедуры, если обычно больше селекта, апдейта/инсерта от базы и не требуется, а вся логка сидит в cpp и вообще она нифига не бизнес

ну да, любимый пострге обидел, хех :) да в горбу я видел этот тормоз для моих задач, пусть он и подходит кому то в качестве комнатного оракла для тренировки и удобной пересадки проекта в потом на настоящего. Пускай наворачивают логику запутанными схемами те, кому это надо по жизни .. База данных гораздо удобнее, чем плейнтекст для многих случаев и программ, вполне сложных самих по себе - только как средство структурированного ввода-вывода данных, с возможностью их селективной выборки - зачем форматировать, крутить и затем парсить многомеговые текстовые файлы если есть реляционные таблицы, к тому же довольно быстрые и доступные, с достаточно гибкими и развитыми серверами баз .. каждый инструмент хорош не "вообще", а для своего назначения, мускул лучшая база для своего круга задач, а о постгре можно сказать, что он лучший хоть в чем то?

> сли обычно больше селекта, апдейта/инсерта от базы и не требуется, а вся логка сидит в cpp и вообще она нифига не бизнес

вот про это я и говорю.

а теперь ещё прошу сказать про гугл: ты думаешь, что индекс хранится в мускле?

на чем именно крутятся параллельные индекс шарды в гугле не знаю, быть может на их фирменном софте, держат, скажем индексы на кластере в виде структур прямо в оперативной памяти, сбрасывая на случай сбоя время от времени данные на те же мускул серверы ..

гугл фс у них для индекса.

мускл применяется как хранилище текстовой банерной сети и всё..

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

Народ, подскажите как к MySQL подключится из php 4.x. Вопрос этот потому (как я понял) что в поставке php 4.x идут библиотеки для версии MySQL 3.x.

P.S. OS win. Не разрешат мне Linux поставить . Спасибо за ответ.

> Народ, подскажите как к MySQL подключится из php 4.x.

например: http://www.mgul.ac.ru/~t-alex/Linux/item/php01.html (в php4 аналогично)

> Пускай наворачивают логику запутанными схемами те, кому это надо по жизни..

Ты совершенно прав - кто ясно мыслит, тот ясно излагает и, как правило, слышал про масштабируемость, трехзвенную архитектуру и прочие приятные вещи...
:)

Хм, лично меня от постгреса в свое время отпугнули

две его фичи, отсутствие присутствия alter table и невозможность делать запросы из нескольких БД в рамках одного подключения.

Первое вроде в восьмерке исправили, а что со вторым?

вшивый менеджер таблиц :)

у постгри замечательная документация. хорошо структурированная. у мускуля намного хуже. а касательно языка - если чел it-шник то он должен знать англицкий

>чё за бред? юникод в постгрес появился раньше, чем в мускле

Может и так, но в доке по нему на тот момент об этом ничего сказано не было, а тут, на ЛОРе, сказали, что не держит и никто не возразил :D

А про MySQL в документации всё чётко и сразу было расписано про кодировки, преобразования, коллэйшны...

в таком случае тебе вообще sqlite-а хватит. избавишся вообще от оверхеда на сетевом взаимодействии

На mail.ru postgresql НИКОГДА не использовался. Был oracle. Вот его и сменили на mysql по причине отсутствия специалиста по oracle.

> кстати, как в постгре сейчас с вложенными запросами? Типа INSERT ... SELECT ...? А с созданием таблиц из результатов запроса? CREATE TABLE ... SELECT ...

ээээ... скорее как там у MySQL с вложенными запросами типа:

SELECT .. FROM (SELECT ...) ...

SELECT ... WHERE ... IN (SELECT ...) ... ?

=)

P.S.: Сие не ради флейма, мне действительно интересно (и нужно) знать как там с этим и когда планируется нормальная работа?

4.1 уже давно в стабильном возрасте :)

> На mail.ru postgresql НИКОГДА не использовался. Был oracle. Вот его и > сменили на mysql по причине отсутствия специалиста по oracle.

хош сказать что на Руси все ясны молодцы, оракловы дба вымерли?

>>Понятно что битые ключи это не смертельно, но такое поведение для нормального сервере IMHO не допустимо.

>Согласен. Битые ключи встречаются. У меня, правда, они автоизлечиваются (REPAIR TABLE в случае ошибки обращения), но это не есть хорошо.

Недавно тоже столкнулся с проблемой битых ключей. База рушилась постоянно. Это, по-моему, ошибка MySQL, точнее, таблицы MyISAM. Хотя после изменения основных параметров в конфигурации сервера MySQL проблема исчезла.

> что ж там нерепрезентативного?

Ты действительно веришь, что пять (очень похожих) запросов могут
считаться репрезентативными для оценки быстродействия? ;) И потом,
ты не замечаешь, что все запросы составлены с определённым смыслом,
имеют похожую кострукцию и могут быть характерны для одного приложения?

> может не понимаешь просто, что мускл не может называться СУБД, пока там нет представлений, процедур и триггеров..

Может и не понимаю. По крайней мере такого определения СУБД я ещё не слышал. Где такое написано? Дай ссылку.

On 14 Mar 2005 13:31:47 +0300

> Может и не понимаю. По крайней мере такого определения СУБД я ещё не
> слышал. Где такое написано? Дай ссылку.

Можно и более простое определение дать. Мускль соответствует ACID? нет
- ффтопку =)

Вот что я видел только что на http://www.ultra-online.ru/:

mysql error: [1129: Host 'x.x.x.x' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts'] in CONNECT(x.x.x.x, '****', '****', ultracomp_test) can't open db connection

Похоже ребята тоже думали что mysql - очень надежная база данных.

>Можно и более простое определение дать. Мускль соответствует ACID? нет
- ффтопку =)

все он соответствует (inodb), но вот убогость sql и остальных прибомбасов не дает его юзать где либо кроме простенького веба.

>Был oracle. Вот его и сменили на mysql по причине отсутствия специалиста по oracle.

Вы бредите. Закнчивайте нести околечицу.

Прекрасно держит либо с 4.0 либо с 4.1 версии я не помню точно. Кусок моего работующего кода
бла-бла..
$query .= " AND anime_id IN (SELECT anime_id FROM server) ";
Остальное вырезал ибо слишком много получается, да и не нужно оно..
стоит MySQL 4.1.9

>Недавно тоже столкнулся с проблемой битых ключей. База рушилась постоянно. Это, по-моему, ошибка MySQL, точнее, таблицы MyISAM

номера багрепортов можно посмотреть?

>mysql error: [1129: Host 'x.x.x.x' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts'] in CONNECT(x.x.x.x, '****', '****', ultracomp_test) can't open db connection

И что тебя так обрадовало? обычная защита от DOS, если с одного хоста начинают массово цепляться и тут же обрывать связь, mysql принимает меры. Кстати настраиваемый параметр. Не нужна защита от DOS, поставь в max_connect_errors "сто тыщщ миллионов" и живи спокойно.

>>Недавно тоже столкнулся с проблемой битых ключей. База рушилась постоянно. Это, по-моему, ошибка MySQL, точнее, таблицы MyISAM

>номера багрепортов можно посмотреть?

Я не слал багрепорты по этому поводу.

>чё за бред? юникод в постгрес появился раньше, чем в мускле

Это в том смысле что слово 'unicode' появилось в pg в документации раньше? По существу на сегодня pg сильно отстал от mysql по charsets/collations

>Я не слал багрепорты по этому поводу.

Жаль. Тогда бы ваши слова звучали гораздо убедительнее.

> в таком случае тебе вообще sqlite-а хватит. избавишся вообще от оверхеда на сетевом взаимодействии

sqlite конечно пошустрее ( http://www.sqlite.org/speed.html ), но если вычисления распределенные и база не сетевая, то так или иначе придется самому реализовывать эту функциональность, например через взаимодействие узлов в кластере, взаимодействие конечно и так есть, но зачем специально организовывать сбор результатов самому, если это хорошо делает mysql сервер посредством DBI, так что хранить данные на локальных дисках узлов нет резона, впрочем sqlite может пригодиться если данные не будут целиком помещаться в оперативной памяти узла и надо будет их локально скидывать и подгружать с диска по мере надобности.. но тогда это уже будет своего рода эмуляция функциональности свопа :) и не факт, что от этого будет какой то выигрыш ..

>>Я не слал багрепорты по этому поводу.

>Жаль. Тогда бы ваши слова звучали гораздо убедительнее.

Конечно. Если бы моей целью было убедить кого-либо в чем-либо, я бы привел доказательства.

>sqlite конечно пошустрее

sqlite пошустрее при правильном использовании и на мелких таблицах. Если вы посмотрите их benchmarks, то заметите, что самая толстая таблица там - 25000 записей.

Уже на сотнях тысяч записей он ощутимо отстает.

>а еще у mysql такая лицензия что зарабатывать используя его можно только купив его. постгри при этом совершенно бесплатен.

Поправочка. не "зарабатывать используя его" а "продавать его в составе своего продукта".

>sqlite конечно пошустрее ( http://www.sqlite.org/speed.html )

Жалко, конечно, тесты со старыми версиями. Но среди них - видно хорошо, в каком месте находится Postgre :)

> Если вы посмотрите их benchmarks, то заметите, что самая толстая таблица там - 25000 записей.

да, так точно - не больше 25к :) не так давно тут было обсуждение бенчмарков mysql vs postgresql, так там прокручивались в тестах миллионы строк, а тут нигде даже 100к нет ..

>И что тебя так обрадовало? обычная защита от DOS, если с одного хоста начинают массово цепляться и тут же обрывать связь, mysql принимает меры. Кстати настраиваемый параметр. Не нужна защита от DOS, поставь в max_connect_errors "сто тыщщ миллионов" и живи спокойно.

Ti yveren v etom ? togda ti pioner ... soplivii . V mysql kagdii connection eto "otdelnii" thread/nitka a ne process. K svedeniyou eti samii tredi imeyout ogranichenie po kolichestvu .... potomy "сто тыщщ миллионов" ne vsegda chvatit ...

>Ti yveren v etom ? togda ti pioner ... soplivii . V mysql kagdii connection eto "otdelnii" thread/nitka a ne process. K svedeniyou eti samii tredi imeyout ogranichenie po kolichestvu .... potomy "сто тыщщ миллионов" ne vsegda chvatit ...

Ну что, аноним, ткнуть тебя носом в документацию, за твой снобизм? Так вот. Ты путаешь max_connections и max_connect_errors. Если ты превысишь max_connections (100 по умолчанию, на самосборных mysql можно увеличивать примерно до 1000 (ограничение glibc), на собранных mysql ab - примерно до 4000, на NPTL - пока всю память не израсходуешь), ты получишь ошибку "Too many connections". http://dev.mysql.com/doc/mysql/en/too-many-connections.html То есть это совсем другие ограничения и совсем другая ошибка.

Та ошибка которая тут в форуме промелькнула - это именно защита от DOS, при превышении количества оборванных соединений значения max_connect_errors. http://dev.mysql.com/doc/mysql/en/blocked-host.html

Пожалуйста читайте доки прежде чем ввязываться в спор.

> Похоже ребята тоже думали что mysql - очень надежная база данных.

Не... скорее всего у них стоит какой-то скрипт в cron'е с неправильным паролем =) Вот на сотый запуск mysql и залочил account =)

> Прекрасно держит либо с 4.0 либо с 4.1 версии я не помню точно. Кусок моего работующего кода бла-бла..

С 4.1 походу (на 4.0.23 не работает)... ну и когда у нас ожидатся действительно стабильно работающий 4.1? =)

>ну и когда у нас ожидатся действительно стабильно работающий 4.1

Начиная с 4.1.4 не было сбоев. Т.е. на 4.1.3 подключивал FULLTEXT с UTF-8, а с 4.1.4 - всё ок.

а релиз, кажется, 4.1.7 был.

>>Я не слал багрепорты по этому поводу. >Жаль. Тогда бы ваши слова звучали гораздо убедительнее.

Пользоватся пользуешься, а элементарно помочь развитию проекта(в том числе и себе) послав баг репорт облом :(

>Пользоватся пользуешься, а элементарно помочь развитию проекта
>(в том числе и себе) послав баг репорт облом :(

Ну я посылал:
http://bugs.mysql.com/bug.php?id=2027

Баг поправили только через *ГОД*, до этого заявляя что бага нету. Причем, этот баг не позволял продолжать использовать mysql. С тех самых пор postgresql жжот.

> до этого заявляя что бага нету.

есть 'can't repeat' и есть 'not a bug', разница довольно большая. Прочитал дискуссию. И где же они заявляли что бага нету? reproduceable test case не было, как смогли повторить, так и исправили.. Не вижу тут причин обижаться на них.

>>>Я не слал багрепорты по этому поводу.

>>Жаль. Тогда бы ваши слова звучали гораздо убедительнее.

>Пользоватся пользуешься, а элементарно помочь развитию проекта(в том числе и себе) послав баг репорт облом :(

Во-первых, если бы это была серьезная для меня ошибка, то багрепорт я бы им выслал, как я это уже делал с одной уязвимостью. А эту ошибку я сумел обойти и так, просто поменяв параметры в файле настройки сервера. Во-вторых, повторить мою ошибку довольно сложно, т.к. база рушилась не мгновенно, а нормально работала некоторое время (несколько часов). Заниматься такими поисками лично у меня нет времени. А в-третьих, у меня нет большого желания помогать проекту с такой лицензией, как у MySQL. Просто GPL я бы еще потерпел, если другого выхода нет (хотя он есть), но эта лицемерная двойная лицензия мне не интересна.

Во блин флем развели! Постгреки с мускулятами пузами меряются! Это же вещи разных классов , хотя обе и субд. Для полноты обсуждений сюда еще можно еще какой нить акцесс прикрутить. Мускуль шустрая субдшка, тока на ней логику упаришься писать - триггеров нет, все клиенте (то биш на апачах) перлом да пхп реализуется. Грустно немного. Логика в постгре пишется легче, да и работает на порядок быстрее, потому как триггера и на с++ писать можно. А по скорости селектов отстает. Вот ежели бы их в одну кучу...

Аксцесс он и в африке акцесс

>но эта лицемерная двойная лицензия мне не интересна.

Поподробнее можно, что в ней лицемерного? Quid pro quo - куда уж честней.