мускуль - лучшая БД!!!!
вот станет стабильной 4 ветка, оракл сдохнет нафиг ваще
:)

Это Вы классно пошутили про Оракул.

Руль 100%-ый, subselect, тригеры, foreign key.... все отсутствует. :)

Оракл не сдохнет, мускулю еще долго и высоко до него.

Кстати, FOREIGN KEY очень даже есть

Вот появятся "transactions", "stored procedures", "references" - или все это уже есть? Если же пока НЕТ, то годится ваш "Мыксель" тока для _мелких_мИнет_провайдеров. О какой надежности можно говорить без трансакций? Разве что клиент на той же машине что и сервер либо данные только читаются и очень редко записываются. Пока же MySQL всего лиш "сервер таблиц" и не более. И ставят его только от бедности либо там, где нужен именно сервер таблиц. Лучще уж (IMHO) Interbase/Firebird. Жду опровержения/подтверждения моей теории.

ZY. A Informix в свое время рулил ....

anonymous (*) (2002-06-14 14:02:17.43) Это - не теория, а утверждение. Причем голословное.

Ах там еше и триггеров нет .... Срвер таблиц и не более!

Кстати а кто мне расскажет что случится если в результате запроса возвращается порядка 10000000 записей? Он все так же вываливается по нехватке памяти (сжирал все до последней капли и подыхал)? Или это уже исправили?

> Руль 100%-ый, subselect, тригеры, foreign key.... все > отсутствует. :)

Тут у кого-то зрение отсутствует. В четверке все будет. И тригеры и транзакции вместе с foreign key. А subselect вроде давно уже есть. Вот только оракле покруче будет, но для 90% контор этого вполне хватит. Все равно теперь большиенство aplication server используют.

Полностью поддерживаю высказывание anonymous (*) (2002-06-14 14:02:17.43) MySQL хорош, когда надо быстро читать данные из таблиц путем несложных запросов. Именно здесь он имеет свой основной козырь - скорость. И соревноваться с ним тут может (судя по всем последним benchmark'ам) только Oracle, который отнюдь небесплатен. А вот если же требудется что-то посерьезнее, то здесь MySQL однозначно отдыхает. Потому как доверить важные данные серверу баз данных, который не поддерживает даже ссылочную целостность (хотя в этом плане и есть подвижки) может только очень беспечный разработчик. Но у добавления всей отсутствуещей сейчас функциональности в MySQL 4.x есть и обратная сторона (как обычно). А именно потеря им своего основного козыря - скорости. Это не только мое мнение, желающие могут откопать в инете несколько статей достаточно авторитетных людей, высказывающих ту же точку зрения. Да и сами авторы MySQL писали в MySQL manual, что "реализация foreign keys серьезно скажется на общей производительности системы". Т.е. получается, что после того, как все это будет реализовано MySQL превратится (через год-другой, когда эта ветка станет стабильной) в ничем не примечательный SQL сервер немного не дотягивающий до InterBase/FireBird или PostgreSQL, но уже не имеющий выигрыша в скорости. И зачем он тогда будет нужен если уже сейчас можно получить все то же самое и даже больше, используя InterBase/FireBird? Тем более, что по тестам при больших нагрузках (100 и более пользователей) InterBase и PostgreSQL работают *быстрее* MySQL. Желающие могут поискать соответствующую статью на http://apachetoday.com

Так будет или уже есть? А про subselect они писали пользоваться join. Как мне зделать нечто типа: select t1.f0 as user, t1.f1 as field1,t1.f2 as field2 (select user_id as f0, min(total) as f1,max(total) as f2 from tbl1 group by user_id) t1

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

О мискеле бедном замолвлю я слово

transactions - в четвертой заявлен - не пробовал пока stored procedures - есть уже - на перле references - извиняйте - не грамотьные мы - не знаем таких фичь

Однако "всякому овосчу своё время " ты же на легковушке на требуешь наличия гидроподемника для багажника И на грузовике пассажиров не возишь

В общем в очередной раз страсти по вопросу что лучше вилка или нож -- и почему народ такой нервный стал ?

Похоже я чего то недопонимаю. Расскажите мне зачем foreign keys на уровне MySQL ? Ну вот у меня веб апликуха на php (или другой aplication server), он у меня и заведует всей бизнес логикой. А зачем мне напригать этой ерундой сам сервер ? Транзакции я понимаю, без субселекта тоже жить не могу. Да и где блин такие нагрузки, что PostgreSQL загинается ? 90% компаний вполне в текстовых файлах могут хранить данные.

> что случится если в результате запроса возвращается порядка 10000000 записей? Он
> все так же вываливается по нехватке памяти

А что ты делать будешь с этими 1000000? Может у тебя 100000 Gbit сетка?
Или на клиентах 100000 GiG памяти?

to anonymous (*) (2002-06-14 15:44:01.894)

Все правильно, если не "возвращается", а "обрабатывается"...

PS
Могу оказать платые услуги по подсчитыванию количества записей после умножения двух таблиц по 10000 записей... ;)


to anonymous (*) (2002-06-14 15:09:29.759)
> Расскажите мне зачем foreign keys на уровне MySQL?
> А зачем мне напригать этой ерундой сам сервер?

Рассказываю. Для сохранения целостности данных. За комментами - в институт на третий курс. Там расскажут. Ещё лучше - почитать литературу. Там умные дядьки подробнее объяснят, зачем это надо.

А если это ерунда, то извините...


wild

Wild вы из какой деревни ? Почитайте умные книжки keywords: middleware, aplication server, DCOM, CORBA

МАЙ СКУЛЬ СОСЁТ !!!!

Ну скажем так. Транзакции есть уже более года. Внешние ключи - околополугода.

А кстати а вы интересно угадаете какая СУБД используется в оффициальном сайте персонала мира по футболу ?

Последнему anonymous'у: Сайт чемпионата мира - не показатель. Там как раз MySQL (если там действительно он) подходит. А вот если MySQL использовать для создания e-commerce проекта, то там, извините, ему не место. Потому как там данные должны быть четко связанной цельной структурой и обеспечиваться такая структура должна сервером баз данных, а не внешним приложением. А то я, например, полезу в каталог продуктов, удалю один - и все заказы на него повиснут в воздухе, т.к. к этому продкуту никак не привязаны.

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

> Wild вы из какой деревни ?

Я за него. Из Мытищ.

> Почитайте умные книжки keywords: middleware, aplication server, DCOM, CORBA

Говно это всё, если сервер баз данных целостность данных не поддерживает. Подумай чуть-чуть - это несложно - в твоей трёхзвенке одно из звеньев заребутилось из-за того что кто-то за проводокъ дёрнул :)

будущее за движками хрянящими древовидные структуры в одной таблице и оперирующими с XML!

Ну по-моему работа с 100000000 записями - это их основной предмет понта, со ссылкой, если не ошибаюсь чуть ли не на крупнейший европейский банк. Насчет транзакций - дык это уже есть в MySQL Max. Ну а насчет всего остального - к Postgres'у. Правда с тормозззами. А Oracle рулит, потому как есть всё быстро, но поскольку небесплатно, то как бы и не совсем рулит... Короче, как бэк-энд для пэхапэ - супер, ну а кому все и сразу - дык это к Оракулу за $$$

Ув. анонимус! "будущее за движками хрянящими древовидные структуры в одной таблице и оперирующими с XML" ага.... и чтоб ентот движок еще и на Яве ;-)) Муйня это полная... Имхо, конечно...

2anonymous (*) (2002-06-14 15:44:01.894)
Что я буду делать с 10000000 записями - это уже мое дело.
Но МуСКуЛ то падает. А вот это уже уже совсем не красиво.
Расскажите мне где написано что результат запроса должен
соержать не более N записей?
И на основании каких стандартов SQL эти лимиты основаны.

А вобщем-то для несложных и не больших задач, как хранилище
информации конечно мускул подходит не плохо. Но до серьезных
и уж тем более ЛУЧШИХ БД ему пожалуй далекова-то.

>> А что ты делать будешь с этими 1000000? Может у тебя 100000 >> Gbit ??сетка? >> Или на клиентах 100000 GiG памяти?

Задача MySQL не в том, чтоб 1000000 записей прокачать по 100000 Gbit сетке, а чтоб из этой 1000000 записей прокачать тебе ОДНУ по модему. Только вот поди найди ее там, да еще и быстро... MySQL с этим справляется. Даже почти хорошо - у нас тут реальная база с (примерно) 2 000 000 записей (нули посчитали?) И ничего, живет... Впрочем, сорри, по-моему это уже флейм и религиозные войны.

2 anonymous (*) (2002-06-14 17:04:49.491)
Присоединяюсь к Дикому и Dimentiy'ю.
Ув. anonymous, если вы пользователь, и приложения, с которыми вы работаете общаются с oracle, поинтересуйтесь у разработчиков, pls., что им (и сколько по затратам и времени, если возможно) стоит перейти на mysql.
Если же вы разработчик, i.e. 'developer', то мне непонятны ваши вопросы, касающиеся целостности данных. Или вам удобнее определить в каком месте произошел сбой, в в третьем commit'e или во втором insert'e, нежели 'отдать' это на усмотрение БД?

satyr.

Блядь, задолбали уже.

1) MySQL Ораклу не конкурент. Две разные ниши. 
MySQL очень долго идти до Оракла, ДБ2 

2) В MySQL есть транзакции и внешние ключи.
Это недоумкам, которые просто лезут пофлеймить.

3) Что за херня про падение MySQL на выборке/обработке миллиона записей? Руки кривые. Я для бенчмарков использую наборы по 10 000 000 записей, и на выходе около полумиллиона.

В общем товарищи флеймеры, кончайте спорить:
Ораклу Ораклово, МайЭсКуЭлю - майэскуэлево.

>те придурки, что никогда не слыхали про reference integrity на >уровне баз данных, пусть подучатся, как правильно говорили. надо ж >быть такими тупоголовыми, чтобы все сильные стороны баз - fkeys, >триггеры, хранимые процедуры, транзакции - перетаскивать на уровень >выше, а базу использовать как хранилище кучи текста.

ссылки пожалуйста. а обосрать и я могу. Если вы из деревни то это ничего не значит. Тригеры и хп - сакс, это точно в сад. Транзакции да без них никак, хотя что такое Trasaction server надо посмотреть. Итак у меня 3 сервера с _разными_ базами, ну и какие нафиг fkeys между ними ? А если базы от разных поставщиков ? я понимаю что некоторые на новеле dbf гоняют и ничего ... зато есть хп и fkeys ...

2anonymous (*) (2002-06-14 20:21:17.734)
Да чего ты так разнервничался? :)

А про кривые ручки - нужно читать получше.
То что в таблице валяется 10 000 000 это еще не о чем не говорит.
Вот возьми и запусти select * from table_with_10_000_000_records.
Т.е. что бы у тебя на выходе было 10 000 000.
Вот тут и начнется пестня. :)

Только не нужно нервишки себе трепать пжалста.
Никто же не говорит что MySQL не умеет искать данные или что
он ползает как черепаха, но что есть, то есть. Кстати PostgreSQL
там же (правда последнюю версию не проверял). Если у PoetgreSQL
запросить большой объем информации, то захрючит всю память и здохнит.

P.S.: Я думаю что эта информация скорее не для того что бы обплевать
MySQL или чего-то еще, а для того что бы те, кто им пользуется, знали
об этом и были готовы к таким ситуациям.

agh.. fuck it!

Microsoft Corporation: We are making the future, join us or DIE.

--- Фанат FreeBSD.

Немного не в тему, но кто что может рассказать из боевого опыта о M$SQL? Особенно интересует о mssql 2000. И еше, знает ли кто, какие у них планы в отношении БД?

запихнуть в виндовс вместо файловой системы и потом всех выкинуть с рынка по нешкаповскому сценарию.

vot.

2 anonymous (*) (2002-06-14 20:36:41.9):
Я разнервничался потому как задолбали откровенно споры людей, которые либо ни хера не знают по теме спора (то бишь даже документацию поленились почитать..это гасчет транзакций и внешних ключей в мускуле), или знают, но тупо флеймят, либо с пару лет не проверяли что-либо и думают что всё так и осталось.

Далее чтоб много времени не тратить на сделал тест на таблице
 int, varchar(250), datetime,  char(100), timestamp из 2 000 000 записей инсерт селект. недавно закончилось. Никто не упал, ничего не разбилось. Куда тебе отвертку для рук прислать? 

Про транзакции я знаю, а вот просветите, foreign keys в 4-й версии только поддерживаются?

В 3.23.* вот что написанно в доке:
The `FOREIGN KEY', `CHECK', and `REFERENCES' clauses don't
actually do anything. The syntax for them is provided only for
compatibility, to make it easier to port code from other SQL
servers and to run applications that create tables with references.

Как сие понимать?

Блин, залез на их сайт и прочитал следующее:
MySQL 4.1, the following development release

Internally, through a new .frm file format for table definitions, MySQL 4.0 lays the foundation for the new features of MySQL 4.1, such as nested subqueries, stored procedures, and foreign key integrity rules , which form the top of the wish list for many of our customers. Along with those, we will also include simpler additions, such as multi-table UPDATE statements.

4.1 еще нет в природе, а значит нет и subqueries, stored procedures, and foreign key integrity rules. Что ж вы пишите то, чего не знаете?

"сделал тест на таблице сделал тест на таблице ... недавно закончилось..." -
Очень веселая фраза - я долго улыбался...

" 4.1 еще нет в природе, а значит нет и subqueries, stored procedures, and foreign key integrity rules. Что ж вы пишите то, чего не знаете?"

Знал бы хоть куда лазить. Почитай Manual там ясно написано что FOREIGN KEYS поддерживается для INNODB Таблиц. Причем последнюю версию MANUAL.

Subqueries и Stored Procedures дейситвительно нет

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

MySQL признаный лидер для организации Web приложений и не даром для этого он очень хорошь. Причем включая огромные базы данных Google, Yahoo.

Конечно этим круг его применений на заканчивается - о чем можно почитать например в Success stories на сайте...

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

> MySQL признаный лидер для организации Web приложений и не даром для
> этого он очень хорошь. Причем включая огромные базы данных Google, Yahoo.

:)))
Замечательная фраза :) Оказывается вот на чем построен Google... Будем знать.

да что вы знаете о ядреных реакторах... ?

//pihta

... ;)

:))) Замечательная фраза :) Оказывается вот на чем построен Google... Будем знать.

Правильно знайте. И далеко не только он.

А насчет ядерных реакторов второму оратору - не согласный что там MySQL НЕ используется ?

SAPDB

Товарищи, кто-нибуь может поделится впечатлениями о SAP DB?

Читал я интервью с создателем Яндекса (забыл, как зовут), он на вопрос, какая СУБД используется, сильно прикалывался, и сказал, что вообще никакой СУБД не используется, а все разрабатывается вручную, специальные СУБД - на С. Он также сказал, что и другие поисковики обычными СУБД не пользуются. И в это трудно не поверить. Google говорит, что знает миллиард страниц - а это много больше, чем вышеназванное количество. Там все распределенное и т.д.

>Товарищи, кто-нибуь может поделится впечатлениями о SAP DB?

Sprosi u rebjat na http://www.rscom.ru . Predlogajut dashe kurs obutshenia.

Не совсем понимаю язвительные наезды на mysql. На сервере лежит база с порядком полутора миллиона записей, общий размер 5.6Gb. Примерно каждую секунду в базе идет выборка. На сервере еще порядка 30 вируальных хостов, все на базах, динамике. Общая загрузка сервека всегода порядка 0,15 - 0,30. железо IP2 400MHz, 256Ram. Так что, может предварительно стоит почитать документацию, научится пользоватся базой - и только потом начать доказывать свое мнение.

IMHO, PostgreSQL пока самая продвинутая из _фришных_ СУБД

Как заставить MySQL хранить данные на диске в зашифрованном виде?

Он вообще это может? Если нет, то какая другая бесплатная БД это умеет?

>вот станет стабильной 4 ветка, оракл сдохнет нафиг ваще вот станут на Запорожцы фабрично ставить спойлер, BMW сдохнет нафиг ваще ... ГЫГЫГЫ .....