МайСкул мастдай. Будущее за Берклей ДэБэ.

Ну во первых никто вам не мешает использовать BerkeleyDB из MySQL...

А во вторых скорее правильно было бы сказать за ней прошлое - навигационные базы данных были популярны этак лет 30 назад.

А разьве MySQL не использует BDB в качестве движка ?

Господа, использовать эту версию не советую, будем надеяться скоро выйдет багфикс. Мне пришлось откатиться до предидущей - регулярно приходящие SIGSEGV мне не по душе.

MySQL рулит!
тем паче для веб-прожектов!

Ой люблю я таких деятелей. У вас падает - делайте баг репорт и пишите на bugs@lists.mysql.com вместо того что плакать. Или пофиксят или объяснят как руки чинить.

А не пора ли перейти на mysql-4.0.5? Я давно перешел. Заметно быстрее, если использовать ее новую фичу - кеш.

Re: MySQL 3.23.54
А не пора ли перейти на mysql-4.0.5? Я давно перешел. Заметно быстрее, если использовать ее новую фичу - кеш.
anonymous (*) (2002-12-14 08:47:21.133)


пока ещё он не стейбля ;(

заипла эта жалкая эмуляция grep-а!! то ли дело ORACLE

И как же она лично Вас "заипла"?

Да все очень просто. Явные признаки клептомании. Оракл можно с удовольствием украсть а MySQL не получится :)

> И как же она лично Вас "заипла"?

Как, как.... ЛИЧНО!!!

> Явные признаки клептомании. Оракл можно с удовольствием украсть а MySQL не получится

У тебя наверное большой опыт!

У как грустно. Видно кто-то вчера упился дешевой водки. Голова болит. На заводе зарплату не платят. Подруга ушла к другому. В общем жизнь не сложилась...

Нет ?

Тогда не понятно почему гной просто из ушей прет ?

товарищу anonymous (*) (2002-12-13 22:47:02.75) сетовавшему на мои кривые руки - багрепорт давно ушел к Монти, и уже получен ответ, обещали все пофиксить. Проблема оказалась в innodb.

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

>>он понятный

Во!!! наконец-то хоть кто-то признался в причинах %)

>>Для баз меньше 500 метров
для таблиц... не путайте пжалуста...

>>он идеален
да ну %))
create type as object .....

?????

Заколебали вы носом в оракл тычить

Оракл не плохо конечно, но select "бабки порядка 10 тыс $ для покупки оракла" from "карман" union select "0$ для mysql" from "карман". Результат выполнения запроса будет для большинства в мользу моськи >:)))

держу пари что большинство не выполняет лицензионное соглашение Оракла, ну так просьба не гнать! Против оракла ничего не имею, может даже наоборот, но коллеги, когда вы научитесь соблюдать законы в области защиты интеллектуальной собственности да будете нормально покупать ПО и соблюдать лицензионную политику, вот тогда и поговорим. Сейчас даже крупные компании покупают оракл с 15-местной лицензией и растягивают ее на 500 человек (не видел еще не одной компании, которая 100% соблюдала бы лицензионную политику).Так что FSF для нашего безденежного совка самое оно если уж мы хотим жить по законам.

(Цитата: ... Россию можно охарактеризовать 1-м словом: "ВОРУЮТ...").

И еще нужно соизмерять задачи и инструментарий
ибо (если подумать) для 80% здесь присутствующих хватит и "легких"
СУБД

>>Оракл не плохо конечно, но select "бабки порядка 10 тыс $ для покупки оракла" from "карман" union select "0$ для mysql" from "карман"

Не совсем понятная мне позиция...
А где же
union
select "зарплата програмерам" from.... ?

существет такое понятие, как стоимомть владения..
так вот, стоимость самих лицензий это только часть этой суммы.
так что совсем не всегда получаеться что бесплатный MySQL дешевле.
Кроме того, часть задачь на MySQL нельзя решить вообше. Часть можно, но через такую жопу, которая неприемлима в организациях с количеством програмеров >=2.

>>(Цитата: ... Россию можно охарактеризовать 1-м словом: "ВОРУЮТ...").
увы... но подвижки есть %) не все сразу...

>>Сейчас даже крупные компании покупают оракл с 15-местной лицензией и растягивают ее на 500 человек
А вот этого я вообще не понимаю.. если крупная компания не может купить себе инструмент для работы, то это "НЕ КРУПНАЯ" компания.. Почему то компы есть за что покупать, а лицензии нет %(




>>ибо (если подумать) для 80% здесь присутствующих хватит и "легких"
совершенно верно, но есть одно большое НО!.
кому то нужно поддерживать и (возможно) развивать приложение.
тепеть пример. Некий програмер Вася написал прикладуху на SapDB у примеру.. все работает все класно.. но через какое то время Вася свалил. И вот беда.. прогу надо доделать.. (либо авария к примеру какая).Где найти спеца в каком то мухосранске который будет знать и легко разбереться в том что написано? Подымет базу из бакапа?
Где найти спеца по Orcale, DB/2, MSSQL понятно.. хоть это и дорого.

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

P.S. Эх, романтична каръера DBA без бакапа... Одно плохо - очень коротка %)

MySQL - хорош для веба. Для него разрабатывать GUI замучаешься, зато скорость - очень приличная, даже на не очень хорошем hardware. А попробуйте oracle на Pent100 поставить? К сожалению, мне неизвестно использование MySQL в виде production unit не на сайтах. Но если посмотреть на финансовое состояние и развитие MySQL, то, видимо, оно нужно. (Жду-не дождусь когда sub-selects & stored procuderes включат 8-)

Интересно, а что есть Berkley DB? И где реализуется?

http://www.sleepycat.com/

>>А попробуйте oracle на Pent100 поставить
oracle7 запросто...
а так как нонещней MySQL по фичам на 7 оракл не тянет, то и тут не все так красиво. Хотя он кнечно побыстрее на простых селектах будет.

кстати, подобные вопросы про сферического коня в вакууме вообщето уже даже не смешны.. мы живем сейчас, и совт должен работать на том железе которое продаеться в магазине. Тобишь oracle8.1.7 вполне сносно (не продакшн кнечно) будет работать и обслуживать на OLTP запросах около 30 пользователей на машинке стоимостью 1000$.
Так что оставте свои p100 для терминалов.. Там им самое место..

<цитата> мы живем сейчас, и совт должен работать на том железе которое продаеться в магазине. </цитата>

Поправочка. Софт должен работать на том железе, которое есть у заказчика.

<цитата> кстати, подобные вопросы про сферического коня в вакууме вообщето уже даже не смешны.. </цитата>

Да-да.. Особенно интересны идеи везде ставить Оракл. Это напоминает врача, кторый всем без исключения больним прописывает УВЧ.

Каждой задаче - свой инструмент, и тот же оракл нафиг не нужен для большинства задач. Можно сказать даже, что учитывая стоимость Оракла - его ниша очень небольшая.

Можете показать на каких SELECT-ах преемущество ORACLE будет наиболее очевидно ?

ORACLE диктует платформу (Solaris/Linux/Windows) кроме того что он платный.

Лично меня устраивает MySQL за исключением (в порядке важности):

1. Нету UPDATE с джойном

2. Нету хранимых прцедур

3. Нету SUB SELECT-ов

Я думаю реализовать это не так сложно. В качестве хранимых процедур можно взять какой-то embeded язык (TCL/Perl/Python/...)

У каждого своя ниша, MySQL довольно быстро работает, при этом соответственно много чего не умеет. Если нужно что-то с большим количеством возможностей и с большим уровнем надежности, да еще и бесплатное, юзайте PostgeSQL.

FireBird всё равно крууучеееее!!!!!

НУ правда он меня ниразу не подвёл
платформы
Linux
FreeBSD
Wondowwwws
и.т.д.

Помоему так никто и не понял о чем я.
Я не о оракле, я о промышленых стандартах. Не нравиться(денег не хватает) вам оракл, ну дело такое. MS SQL к примеру, Informix, Sybase..

>>Каждой задаче - свой инструмент
верно.. блин.. но где взять людей которые будут поддерживать эту задачу после того, как свалит ее разработчик? А разрабочик был красноглазым, считал себя крутым кулхакером, понаписывал своих функций и вкомпилил их в бинарь MySQL, пользовал другой тип таблиц и никому об этом не сказал. Док не оставил и все. Теперь авария. Ваши действия? нужно востановливать из бакапа. Пусть вы даже трижды бог в познаниях 2 метровой доки по MySQL (блин, смешно даже, дока на SQL серер влазит в 2 метровый html файл).
Раскажите ваши действия пожалуйста? лично мне в голову ничего не приходит.



>>Можете показать на каких SELECT-ах преемущество ORACLE будет наиболее очевидно ?

Для тех кто в танке. Оракл не всегда быстрее.. Кроме того, на простых запросах заметно медленее. А терперь попытайтесь догодаться почему его таки используют.. (хинт, мотоцикл тоже быстрее грузовика).

>>Лично меня устраивает MySQL за исключением (в порядке важности):
для веба меня тоже MySQL утсраивает, но в вебе денег нема %(

то что вы перечислили в недостатках, это лишь малая часть, того чего не умеет MySQL. Мне трудно определить, что важнее сабселект или триггер к примеру, но пока он не умеет элементарных вещей, которые умеет 7 оракл (который до сих пор трудиться кое где)

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

>>Каждой задаче - свой инструмент
верно.. блин.. но где взять людей которые будут поддерживать эту задачу после того, как свалит ее разработчик? А разрабочик был красноглазым, считал себя крутым кулхакером, понаписывал своих функций и вкомпилил их в бинарь MySQL, пользовал другой тип таблиц и никому об этом не сказал. Док не оставил и все. 

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

mysql, mysql... кушали мы его... как только количество инсертов в секундц становится больше какого-то числа, лок на таблицу начинает занимать огромное время. select count(*) from table; на таблице из 400тыс записей выполнялся около минуты. Кышмар... А то, что подзапросы они который год уже пишут... меня create temporary table постоянные задрали. А хреновейший оптимизатор запросов... А как здорово начинает увеличиваться время выполнения запроса, если не найдено данных... Короче, у mysql есть ниша, но она несколько уже, чем это принято считать. Никуда от оракла я в итоге не делся, а переписывать кучу запросов пришлось.

[cite]кстати, я не буду приводить даже список, того чего нет в MySQL, потому как большая часть аудитории все равно не поймет что это такое и почему без этого нельзя строить корпоративные приложения.[/cite]

Все-же хотелось бы узреть.

До чего же народ упертый и тупой. Cчитает что если что-то не делает мускул то потому что глупые разработчики просто не смогли реализовать эту возможность. Дети, не могут понять одну вещь - сделано это НАМЕРЕННО - чтобы получить максимальную скорость на конкретном множестве простых запросов, которые часто составляют более 90%-95% запросов к SQL серверам. Потому mysql и является лучшим и быстрейшим сервером для конкретных задач. Существуют сотни и тысячи задач к которым монстров типа оракла лучше близко не подпускать - просрут вчистую. Новые возможности внедряются осторожно и после серьезнейшего тестирования. Даже маленькая фичка, вроде бы удобная для программера - может обернуться очень серьезным и часто неоправданным снижением производительности. Уперекать mysql в простоте и неполновесности равносильно презрительному отношению к ассемблеру или C - за их низкий уровень. Лично мне очень импонирует четкая позиция разработчиков мускула которые точно оринетируются на конкретную сферу применения сервера в которой он является безусловно лучшим и при этом не страдают от комплекса неполноценности от отсутствия фичастости и полноценности используемого подмножества sql.

И вообще что это за мифические "коропоративные" базы или приложения? Всегда имеем дело с конкретным случаем. В одних случаях без Оракла вообще жизнь представить трудно - в других это явно не лучший выбор. Умение его сделать и называется профессионализмом в отличие от пионерской гигантомании. Пионеры всегда норовят наворотить ТаджМахал на пустом месте - компенсируя свою ущербность наворотами и "комплексными решениями" а дополнительные расходы фирмы или заказчика на офигительную лицензию или брендовое железо играет роль жертвенной коровы перестраховщика на алтаре бога Шухера.

> как только количество инсертов в секундц становится больше какого-то > числа, лок на таблицу начинает занимать огромное время. select count(*) > from table; на таблице из 400тыс записей выполнялся около минуты.

Вчера гонял BDB vs. MySQL на 400тыс. записей. Общее время у обоих сравнимое и примерно равно 250 секунд. Запрос, аналогичный Вашему -- 1,5 секунды. Но... Это с индексами. В MySQL без индексов процесс тестирования крутился всю ночь и так и не завершился. Может, проблема все таки в правильной индексации?

> А то, что подзапросы они который год уже пишут...

А это являются частью стандарта SQL92? Ребята тщательно отбирают фичи для реализации, чтобы не упала производительность. Это политика, причем честная -- или скорость или функциональность.

Правда, знаю я одну контору, где для внутренних нужд разрабатывают имитацию хранимого кода на Python. Но во-первых, в случае потери производительности будут пинать не разработчиков MySQL, а во-вторых, одним нужен Python, другим -- Perl, третьим еще хрен знает что. Разработчикам MySQL такой геморрой нафик не нужен, их специализация -- скоростной доступ к данным. Да и загонять людей железной рукой к счастью еще одного нестандартного языка программирования они не хотят. Это тоже политика.

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

Ну тут не все так катострафически...

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

Во вторых, синтаксис PL/SQL (&Java) достаточно грамотен(ы), чтобы в чужом коде разобраться за приемлемое время. (это не перл). Кроме того, вся логика (вместе с коментриями) храниться централизовано на сервере. И если разрабочик не полыный убдюдок, то хотябы описание функций он оставит.

В третих, среди ораклистов куда меньше распостранены стремление "самовыразиться" и идти "своей дорогой". Дак как инструменты на все случаи жизни уже придуманы. Посмотрите какое количество пакетов ставиться по умолчанию. Еще больше, можно доставить самому. Я еще не придумал не одной задачи, короую бы нельзя было решить стандартными функциями из sys.package. Блин, хоть по вебу через оракл лазь.

В четвертых бакапирование (особенно горячее) стандартизировано и переносимо в пределах ветки по любым платформам.

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

>>И вообще что это за мифические "коропоративные" базы или приложения?
Самая простая характеристика это количество постоянных разрабочиков >=2. Вторая, это там, где потеря или искажение данных автоматически приведет тебя к увольнению (в лучшем случае). Если в складской програме "поплыл" баланс, то виноват только разрабочик. Никакие отмазки на кривых пользователей, сдохшую базу, железо, и прочее тут не катят. ну есть кнечно и еще отличия..

>>Все-же хотелось бы узреть
билин, да 10 раз уже здесть только я писал.. 100 раз уже другие писали.
В последний раз, только для тебя
пока не поймешь что обозначают эти строки, не задавай больше глупых вопросов (сорри, если где опишусь. пишу c головы)

create type person as object
(
firstName varchar2(31),
secondName varchar2(31),
decsriprion clob,

member function getFullName return varchar2
) not final
/

create type redEyes under person
(
preferenceRDMS varchar2(31) default 'MySQL',
salary varchar2(31) default 'very small'
)
/

create type students as table of redEyes
/

create table groupPeoples
(
id number,
description anydata,
people students
)
nested table people store as table_of_redEyes
/

и т.д...
я уже не буд распостраняться на предмет XML/XSLT. Вприципе вообще отпадает необходимость во всякого рода php и прочего.. с базы вообще можно вытаскивать сразу готовую HTML(XML) страницу. Скормил серверу запрос, XSLT таблицу и получил готовый HTML.

А можно я от имени убогих и слабоумных еще один вопрос задам? А мочему я все это не могу сделать, скажем, в EJB, или CORBA, а в базе хранить данные (то есть использовать инструмент по назначению - базу данных - хранить данные)

> Док не оставил и все. Теперь авария. Ваши действия? нужно
> востановливать из бакапа
вот именно!
втыкаем новый серверный винт в машину админа
mount /mnt/usr
mount /mnt/db
cd /mnt/usr
restore xf our_cool_usr.dump
cd ../db
restore xf our_cool_db.dump
cd ..
umount usr db
втыкаем обратно винт в сервер

isamchk или чгео-то там - по вкусу.
если же у Вас нет *.dump - Вас как админа надо выганть за профнепригодность.
и совершенно пофиг что программеры натворили.

>>А мочему я все это не могу сделать, скажем, в EJB, или CORBA,
для начала вопрос, понятно что я там вверху написал? Если да, то попытайся %).
Как говориться, желаю удачи.
Когда тебе прийдеться документировать формат данных, а также дописывать модули может быть догадаешься, почему такой путь многие называют "через жопу".
если тебе удасться при этом избежать локов и сохранить целостность, кроме того, не уронить производительность и затратить хотя бы в 5 раз меньше времени это будет достижением.

кстати, а как ты будешь осущестлять поиск в данных? Неужто конектится, вытаскивать все данные из базы и делать поиск во внешней прикладухе?? скорость всего этого предсталяешь??


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

<цитата>для начала вопрос, понятно что я там вверху написал? Если да, то попытайся %). Как говориться, желаю удачи. Когда тебе прийдеться документировать формат данных, а также дописывать модули может быть догадаешься, почему такой путь многие называют "через жопу". если тебе удасться при этом избежать локов и сохранить целостность, кроме того, не уронить производительность и затратить хотя бы в 5 раз меньше времени это будет достижением. </цитата>

Таак, понятно. Сознайтесь сразу - ни в EJB ни в CORBA вы ни в зуб ногой. Судя по вопросам, которые вы ставите - вы некомпетентны в этом.

Насчет производительности - EJB или CORBA сервер - это дополнительный кэш, который дает заметный заметный прирост performance.

Насчет документирования - посмотрите что такое к примеру IDL, (или хотябы javadoc для начала, чтобы не лезть в дебри). Посмотрите к примеру как из UML делаются java beans (или те же corba обьекты)

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

</цитата> кстати, а как ты будешь осущестлять поиск в данных? Неужто конектится, вытаскивать все данные из базы и делать поиск во внешней прикладухе?? скорость всего этого предсталяешь?? </цитата>

Не позорьтесь. Прикладуха сообщает чего хочет найти corba серверу, тот генерит SQL запрос SQL серверу и возвращает ответ прикладухе

<цитата>ну и... где ты возмешь модифицированый бинарь? </цитата>

Это не Оракл. Берем исходники Mysql, берем патчи от твоего шибко умного программиста и делаем новые бинарники. Кстати, а что, ваш сисадмин бекапил только базы? Полагается бекапить _все_ файлы которые отличаются от дистрибутива.

2 ifconfig
>create type person as object

Да в этом отношении Oracle, конечно, очень продвинутая штука, девяточка особенно. В MS SQL, на котором пришлось пописать приличное время о таком приходилось только мечтать. Но я глубоко против исключительной позиции Oracle в этом отношении. Если вы немного потратите время на и посмотрите на тему объектно-реляционного преобразования чуть шире Вы найдете немало очень интересных вещей. EJB QL for example. Мне очень нравиться Jakarta OJB - получаю почти полную независимость от вендора RDBMS, когда не надо EJB-нить.

>я уже не буд распостраняться на предмет XML/XSLT

А почему бы к стати и нет?. Очень скромное IMHO - всё должно быть очень тиерным и модульным и XSLT - это последний этап работы скажем StrutsCX. А засовывать это все в базу - так сколько ж архитектурных проблем плодить в будущем? Я, конечно всего Вашего хозяйства не знаю, но все же..

Я противник отношения - мое и круто.. :(( Oracle и MySql вовсем разные продукты. Цели, задачи и ниши у них совсем разные. Разумеется глупо считать склады на MySql, но также неразумным мне кажется использование (лицензионное разумеется) Oracle для не самого крупного сайта.

Последнее время очень нравиться PostgreSQL. Там где нет Sun Fire и сотен k$?, но нужна надежность. По возможностям мало чем уступает Oracle. Расширять легко и удобно. Стабильности можно позавидовать, а насчет зрелости, так AFAIK разрабатывается с 1977 года. Вот только не знаю насколько он соответствует промышленным стандартам... :))))))

Мое очень скромное IMHO... :)))