Ну вот...Хорошая новость, но сейчас наползет анонимусов и начнется флейм "MySQL vs. другойSQL", выяснение кто у кого сосет и т.п...

MySQL ползуются только ЧМО и ацтои!

а Rolex у нас второй Нострадамус оказывается :p

блин, задолбало уже - набролось качу ламаков, которые прочитали книжонки по PHP и MySQL и теперь считают себя крутыми программерами: и смеют еще говорить, что MySQL это типа крута чуваки. Ничего слаще моркови не ели, а делают такие утвержения про этот grep c поддержкой SQL (да-да, это я про ваш любимый мискль).
Миллионы мух не могут ошибатся! PHP+Mysql=руль форева!
Достали ламаки уже......

Я не анонимус, но таки PostgreSQL получше будет. Хотя и MySQL в некоторых задачах всем фору даст. Так что вибирать надо софт под задачу, и совсем неважно -- греп-ли это или крутой (?) Оракл.

to aim1159: А что тебе Оракл сделал, что ты его с (?) публикуешь ?
Да, согласен, что про софт надо говорить что он не
хороший/плохой, а хороший/плохой для _конкретной_ задачи.
Да, для написания гостевухи - PHP+MySQL - это есть круто.

А кто-нибудь пытался написать на нем запрос с третьим уровнем
вложенности и иерархическими выборками?

И не надо говорить, что для этого есть Perl или PHP, а писать
это на SQL - изврат - до тех пор, поскольку каждый запрос к
базе жрет время, а _мой_ _опыт_ показывает, что эффективнее
дать один сложный запрос чем постоянно дергать базу, и самому
орудовать в Perl'e. (А зачастую мне на такие вещи почему-то
вообще говорят про select * from Имя_таблицы с последующим
раскапыванием этого маразма в Дельфях(?) )

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

Видно, об эффекте "лоскутного одеяла" они ничего не слышали.
Мухи надо хранить отдельно, котлеты отдельно, господа.
И не смешивать логику работы сайта с дизайном (это уже про PHP)

Извините, это я уже о наболевшем...

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

MySQL - руль форева! (для простых задач :) )

ИМХО такого рода новости должны идти отдельной колонкой сбоку,
с change logom и ссылкой откуда скачать. И никакая дискуссия тут на#ер не надо, по крайней мере до версии 4.00.00 в случае, например, с MySQL. А то вышло 3.23.52, вышло 3.32.53, вышло 3.32.53.1,
вышло 3.32.53.1а. вышло ....
По теме флейма:
> ... про этот grep c поддержкой SQL ...
В 99.5% согласен!
> ...MySQL в некоторых задачах всем ...
В том то и дело, что только в _некоторых_.
> ...Mysql это радость бесплатным хостерам и ничего хорошего
крупным разработчикам ...
От себя добавлю, что как правило ничего хорошего и средним разработчикам.

> а делают такие утвержения про этот grep c поддержкой SQL (да-да, это я про ваш любимый мискль).

Вы уверены, что это Ваше. В оригинале зто было "grep с синтаксисом SQL".

Да, oracle как минимум не хуже, если контора его купила. Ваша контора купила oracle? Если да, поздравляю. Вы можете гордо насмехаться над "качей ламаков".

Мы купили oracle, вместе с неким приложением под него, и, пользуясь этим, свои прибамбасики мы лепим, в основном, под него. Но никому из наших "пацанов" не прходит в голову обсирать другие SQL-серверы. Даже MSSQL.

MySQL изумителен по красоте. Чего Вам в нём нехватает? Хранимых процедур? У Вас в руках исходники, дописывайте. Не умеете? Вам в руки библиотека mylua.

"Чиста моё имхо": коммерческие СУБД вынуждены поддерживать встроенный язык (pl-sql, tranzakt-sql (не ручаюсь за правильность написания, поздно и много было пива)) потому, что они не опен сорс.

На счёт морковок, с Вами согласен.

By.

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

А есть альтернатива?

Я так понимаю, что в мире опен соурс есть две альтернативы:
1) Навароченный и тормозной PostreSQL
2) Быстрый и простой (примитивный?) MySQL.

Я что-нибудь пропустил?
Только речь идет о том, что действительно можно применять, а не про поделки "Для себя".

>Я что-нибудь пропустил?
firebird - нечто среднее
и еще десяток концептов.

> 1) Навароченный и тормозной PostreSQL

Кто-нибудь объяснит, в чем его тормознутость? Кроме seq scan для агрегатов (индексы не используются) -- это известная проблема. Ну а кроме этого?

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

> А кто-нибудь пытался написать на нем запрос с третьим уровнем
> вложенности и иерархическими выборками?

А кто-нибудь пытался разбить этот запрос на три? ;)

> И не надо говорить, что для этого есть Perl или PHP, а писать это на SQL - изврат

Однозначно изврат.

> поскольку каждый запрос к базе жрет время,

Как раз таки на mysql и не жрет ;)

> а _мой_ _опыт_ показывает, что эффективнее
> дать один сложный запрос чем постоянно дергать базу,

а мой опыт показывает, что эффективнее дать несколько простых запросов... ;)

> Так что, Mysql это радость бесплатным хостерам

И где ты видел беспланых хостеров с mysql? Может подскажешь адресов? ;)

> и ничего хорошего крупным разработчикам

Нет, есть один очень хороший момент: mysql учит еще не испорченных программистов
эффективно программировать. Тебе это уже не поможет ;)

libpq vs. libdbi ?

Пользуясь поднявшимся флеймом хочу спросить: какая библиотека для доступа к Postgre лучше? Родная или платформо-независимая? Или лучше так: какие у dbi ограничения?

P.S. Вот тут-то мы и увидим кто ламер ;-) P.P.S. Особенно, если никто не ответит ;-)))))) на это сообщение

SadAlex.

уже не 1-й год использую mysql в биллинговой системе реального времени. Единственное, чего не хватает - это процедур - приходится всю логику писать в клиенте. Нагрузка - смотрите сами (3 дня uptime - на ups'е предохранитель перегорел - пришлось выключать сервак):
#mysqladmin -p status
Enter password:
Uptime: 279723 Threads: 1 Questions: 128090 Slow queries: 5 Opens: 53 Flush tables: 1 Open tables: 47 Queries per second avg: 0.458

Ни единого нарекания за 2 года работы - так что подумайте, что говорите про grep+SQL, когда ругаете MySQL

2anonymous (*) (2002-08-19 22:03:54.607)
я работал с postgresql только на линуксе через 2 интерфейса
libpg C library и JDBC.
libpg C
Удачно написаная компактная библиотека, но есть один минус - требует весьма аккуратного программирования. (не сделаешь один раз PQclear (res); и через пару итераций можешь получить segfault, а можешь и не получить. Отдебажить такое трудно, поэтому нужна хорошая культура програмирования.

JDBC
люблю яву и jdbc. Драйвер стабильный работет как часы.

2 mazay (*) (2002-08-19 22:53:08.427):
Это что за биллинговая система с uptime в 3 с половиной дня ?
И таким маленьким количеством запросов.

Вот параметры от 30 дневного uptime совсем даже не на биллинговой системе:
[root@server1 /root]# mysqladmin -p status
Enter password:
Uptime: 2610716 Threads: 2 Questions: 295243085 Slow queries: 213 Opens: 17120 Flush tables: 1 Open tables: 64 Queries per second avg: 113.089
[root@server1 /root]#

Но на MySQL не жалуюсь - действительно глюков не было.

2anonymous (*) (2002-08-19 17:59:01.026): запрос произвольной вложенности можно переписать как линейный, но не более. И если ты не понимаешь, что запрос с тройным уровнем вложенности не есть три запроса, склееные через UNION, то сгинь и не позорь MySQL такими с позволения сказать "аргументами". "а мой опыт показывает, что эффективнее дать несколько простых запросов..." - твой опыт врет, поскольку, если ты "сводишь" результат трех и более больших запросов в одном, сервер БД сделает это намного лучше тебя, будь ты даже немеряно крут (в чем я очень сильно сомневаюсь) "... Тебе это уже не поможет ;)" - сначала сам сходи поучиться (хотя бы в библиотеку почитать книги ныне покойного Э.Дейкстры)

> твой опыт врет, поскольку, если ты "сводишь" результат трех и более
> больших запросов в одном, сервер БД сделает это намного лучше тебя,
> будь ты даже немеряно крут

Если я в чем и крут, так это в том, что всегда сразу же предлагаю
болтунам проделать тест и показать его результаты ;)

select username, st.month, st.year, st=sum(v1.sum), sv=(v2.sum), se=(v3.sum) from users, v1 (select userid, month=month(datep), year=year(datep), sum=sum(sumplat) from platv group by userid, month, year), v2 (select userid, month=month(datep), year=year(datep), sum=sum(sumplat) from platt group by userid, month, year), v3 (select userid, month=month(datep), year=year(datep), sum=sum(sumplat) from plate group by userid, month, year) where v1.user=users.userid and v2.userid=users.userid and v3.userid=users.userid and v1.month=v2.mont and v2.month=v3.month and v1.year=v2.year and v3.year=v2.year

Записей в plat* примерно по 300 тысяч в каждой... Несложный такой запрос с группировкой по абонентам, месяцам по данным трех таблиц различных классов платежей. Нормальный сервер выстраивает три подзапроса во временные таблицы, прицепляет к ним временные же индексы на поля userid, month и year, и затем строит финальный отчет - легко и непринужденно. Делать то же самое на MySQL, да без подзапросов... А если таких запросов два десятка??? Все программировать??? Читайте книжки и учитесь оперировать множествами, а не записями - вы же не с клиппером работаете, а с SQL-сервером...

Впрочем, мог ошибиться в синтаксисе языка - давно это было слишком, успел подзабыть SQL...

Ты забыл указать самое главное - результаты в цифрах, название твоей
СУБД и параметры железа. С чем сравнивать-то будем?

<цитата автор=no-dashi>
select username, st.month, st.year, st=sum(v1 .... и тд.
</цитата>

Ну и? В mysql это делается четырмя запросами. 3 - создание временных таблиц (с возможностью выбора - где разместить (в памяти или на диске), какие индексы создать, и с возможностью использовать эти вр. таблицы в других запросах) и один результирующий. И по скорости - скорей всего в mysql получится быстрее. 

Плюс к тому - запрос получится гораздо более читаемый. (И значит 
его легче сопровождать/отлаживать/обьяснять другим)

Кстати 300 тыщ - это не размер для базы. Хороший сервер засосет эту базу в кэш. 

На самом деле все еще проще.
Вот так бы я написал для mysql:

my $i;
my @res = ();
my $uid = 'someuser';
my @plat = ('', 'platv','platt','plate')

for ($i=1; $i <4; $i++)
{
    $res[$i] = $dbh->selectall_hashref(
	"select userid, month(datep) as month, year(datep) as year, "
	"sum(sumplat) as sum from ". $plat[$i]." 
	"where userid = \'$uid\' ".
	"group by userid, year, month");
	
};

И плюс отдельно select username from users;

Далее вывод в html. Общая сумма по каждому платежу (типа 
st=sum(v1.sum)) считается тут же, в процессе вывода. Нафига козе баян,
если у нее есть гармонь? 
Вот эта хрень - "where v1.month=v2.mont and v2.month=v3.month" вообще
нафиг не нужна, если известно, что клиент платит по всем видам платежа
каждый месяц. А если это не так, то тогда это условия вообще не имеет 
смысла. Поскольку ты пропустишь платежи в таком случае...

Разницы в обьеме данных на самом деле нет. Разница в том, какой процессор считает(на сервере или у клиента) и сколько качается по сети. Следовательно, в системе "дорогой сервер и дешевые клиенты" или "медленная сеть" быстрее будет SQL, в случае "дешевый сервер, дорогие клиенты и быстрая сеть" - клиентская программа.

Если это все на одной машине разница не так велика, но:

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

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

2anonymous (*) (2002-08-22 11:35:50.627)

Шибко кривое объяснение. Скажем, качается по сети практически одно и то же. Смотри выше пример, приведенный товарищем дашь-не-дашь. От SQL в
обоих случаях мы не уходим. Промежуточный сервер приложений между базой
и клиентами может быть и в том и в другом случае. М про быструю/
медленную сеть тоже надуманная проблема. Ты забыл, что есть еще вариант
"терминал-сервер", где преимущества/недостатки сети сводятся к нулю.

> первый вариант позволяет оптимизацию без вмешательства в программу
Ну чушь это. Есть бесчисленные разновидности твоего первого и второго
варианта.

Re*3: SQL vs клиентские программы

"""Шибко кривое объяснение"""
Да. :-) Уточняю. Первый вариант - предложеный no-dashi навороченый SQL. Второй - перловый скрипт от тезки-анонимуса.

"""Скажем, качается по сети практически одно и то же"""
В случае SQL качается результат, а в случае 'for($i=...' - данные для его вычисления. Не всегда, но может быть существенная разница.

"""От SQL в обоих случаях мы не уходим"""
В том то и дело. В обоих случаях используются недостатки SQL, только в первом еще и достоинства учтены.

"""про быструю/медленную сеть тоже надуманная проблема""" 
Скажем так: крайне редкая:-)

""""терминал-сервер", где преимущества/недостатки сети сводятся к нулю"""
Правильно. Именно в этом случае большуй разницы не получить(если не уйти от SQL). Об и писал(извините, если плохо выразился), повторю: cложный SQL (чаще всего) может дать меньший обьем пересылок в памяти и форматирования передаваемых данных. И позволяет не меняя программ изменять алгоритм обработки за счет(hints, index, statistics). Во втором - переписывание программы.

"""Есть бесчисленные разновидности твоего первого и второго варианта"""
Не спорю. Но обобщать нас не зря ли учили? :-)

> В случае SQL качается результат, а в случае 'for($i=...' - данные для его вычисления.

Вот блин, и такой народ кричит "mysql sux!". Ты хоть на глаз бы оценил
вывод того большого sql-запроса. Видно глаз у тебя не того ;)
Большой запрос выдает по сети ровно такой же объем, как и предложенный
вариант с циклом на перле. Только во втором случае задача для
sql-сервера на порядок проще, а значит CPU у нас юудет загружен
гораздо меньше, вопреки сложившимся стереотипам.

> cложный SQL (чаще всего) может дать меньший обьем пересылок в памяти

И при этом так подгрузить и без того тормозной "большой" sql-сервер,
что за то время что он думал, можно было прокачать пять раз чуть более
длинный результат даже по самой медленной сети.

Вот на таких подвохах mysql и выходит безоговорочным победителем,
вопреки теориям больших бородатых дядек и предположениям тех, кто их
слушает. Больше практики господа!

Блин одни ненормальные тут собрались...

1. "mysql sux!"

Сам сказал :-). Я этого не говорил.

2. "Ты хоть на глаз бы оценил вывод того большого sql-запроса"

Ну, допустим, пример плох - это не меняет сути спора(сложные запросы vs простые с последующей обработкой). 

3."Только во втором случае задача для sql-сервера на порядок проще, а значит CPU у нас юудет загружен гораздо меньше"

Не спорю. Зато у клиента больше:-). Хорошо, если клиент удаленный(настоящий), а не приложение, производящее HTML *на той же машине* :-) - довольно распространенный случай IMHO.

4."И при этом так подгрузить и без того тормозной "большой" sql-сервер"

На то он и сервер, чтобы работать:-) разве не так?

5. "mysql и выходит безоговорочным победителем"

Не опускайся до спора "какой SQL сервер быстрее". Победителем выходит не mysql, и не "не-mysql". В каждом конкретном случае быстрее будет одна из технологий его (SQLсервера) применения. Случаев же много - не забыл?

Так вот попробуй оспорить: При подходе "максимум в SQL" - 

й)  обьем *лишних* операций преобразования форматов не превышает таковой при варианте с простыми запросами

ц) Оптимизировать систему может DBA, не знакомый с perl/др. И при этом в худшем случе упадет скорость выполнения запросов

у) потребное для вычисления результатов операций не превышает таковое для простых запросов((й) не учитываем)

Следовательно, если мы не будем требовать "все записи" - а попросим по сложным правилам выбрать необходимый результат, *должно быть* быстрее с большим SQL.

NB! Собственно никто же и не спорит, что при перегруженом *вычислениями* сервере переложить часть работы на процессор клиента - доброе дело. Тогда действительно выгоднее простые запросы. Но подозреваю, что таких использований mysql (относительно остальных) немного.

> Ну, допустим, пример плох - это не меняет сути спора

Да, да, да! Вспомни, почему вообще появился тот пример?
Потому, что я попросил крикуна подтвердить на деле его слова!
Ты в-точности повторяешь его путь. Догадайся с трех раз, о чем
я тебя сейчас попрошу... Правильно, подтвердить на деле твою
штампованную теорию, которая надоела хуже заевшей пластинки.

Дай свой, хороший пример!

Специально для последнего анонимуса: 4.5 секунды на всеь запрос - Oracle 8.1.6, P-IV 1660, винт IDE, по 300 тысяч записей в каждой таблице (1000 абонентов, 25 записей каждый месяц на каждого абонента в течение года). Жду результатов для MySQl'а - если не дождусь в течение двух недель - ты последнее трепло, последний анонимус...