LINUX.ORG.RU

Правда о Mysql?


0

0

Господа мне нравится Mysql! Но один умный друг сказал,что при большом количестве подключений сервер паршиво работает и даже валиться? Мне нравится большая скорость работы сервера Mysql. В чем преимущество Oracal(транзакции Mysql уже поддерживает). Быстрее ли он работает чем Mysql? Нет ли у Вас впечатления, что он работает сам на себя.

anonymous

Не слушай особо умных друзей :) Пользуйся если нравиться, Оракл намного тяжеловеснее будет, они для разных областей заточены. Если проект небольшой то MySQL'я вполне хватит и запас на будущее тоже есть.

Bauron
()

костыль это, а не транзакции.
Но для небольших проектов мускуль вполне уместен.

Havoc ★★★★
()

Господа уточните мне пожалуйста! Явные минусы Mysql: -Есть ли ограничения по количеству таблиц их объему? -Количеству бд? -Есть ли проблемы с сервером Mysql при подключении большого количества пользователей? -Какая специфика у Oracal(для каких он задач предназначен)? -Если провести странную параллель между Mysql и MSSQL то что круче?

anonymous
()
Ответ на: комментарий от anonymous

2 start with:

Oracal doesn't exist... - its Oracle.
MySQL - fast, supports transactions OK. You need to download MySQL MAX for this
It generally doesn't have any problems with the number of connections.
The minus of MySQL is that it isn't fully complient with the latest SQL standard,
it doesn't support stored procs, views, etc, has rather poor LOCKing techniques.
(It was announced quite a while ago that the ROW locking technology ll be implemented
 in mysql but i haven't heard anything about it being actually implemented)
But, inspite of the abovementioned it is one of the best solutions for 
small - medium projects.

Oracle is God of the databases, but to use it in any project of the medium size
 would be like using a nuclear warhead to shoot down flies.

PS MySQL is faster than PGSQL. PGSQL is fully SQL'92 complient.
PPS Am interested in the info on MySQL vs Oracle speedwise on different types of queries

anonymous
()

а как в MySql поддерживается целостность данных и реализованы ли
хранимые процедуры и триггеры?
если этого нет то ничего серьезнее телефонной книжки не напишешь.
Я пользуюсь Pos-Sql & IB 6.0 и очень доволен (для так скажем средних и малых проектов 30-50 таблиц и ~50K-100K записей)

kirill_s
()
Ответ на: комментарий от kirill_s

2 kirill_s
а как в MySql поддерживается целостность данных и реализованы ли 
хранимые процедуры и триггеры? 
they aren't supported (read previous message), but it doesn't mean 
that you can't write anything serious with mysql, you just need to 
tak care of things manually.
Postgress SQL is more complete and SQL-standard compliant but slower generally
 than MySQL.

anonymous
()

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

Havoc ★★★★
()
Ответ на: комментарий от Havoc

Автор. Господа большое Вам спасибо за Ваши ответы! Смысл моей задачи состоит в том,что моя бд. содержит несколько таблиц число записей Ёгде-то >=130000 (с ну координатами астероидов). Необходимо обеспечить доступ большого количества пользователей к ним, необходимо оперативно обновлять бд (мне важна скорость). Я предпологаю на следующем шаге добавить новые таблицы с координатами комет (число записей несколько миллионов). У меня происходят всякие вычисления и мне важно, что бы сервер бд не тормозил. Другой вопрос к ученым людям! Есть всякие сложные вещи хранимые процедуры, тригера и т.д. Сильно ли они тормозят работу сервера б.д. и не оптимальнее ли переложить "это" на сервер-приложений? Для каких задач нужен Оракул (мой кругозор ограничен задачами баллистики)?

anonymous
()

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

Хранимы процедуры можно, конечно, вынести на Application Server, но для этого ж этот сервер надо поднять :)
ХП - это всего лишь кусок SQL-ля (обычно)
Триггер - таже ХП, только вызывается автоматически по какому-то событию.

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

Havoc ★★★★
()

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

Havoc ★★★★
()
Ответ на: комментарий от Havoc

Совсем празный вопрос: -В какой области нашей совковой жизнидеятельности возникают такие задачи, где объемы информации достигают сотни Гб и имеют столь сложную структуру. Ведь заводы и фабрики стоят?

anonymous
()
Ответ на: комментарий от anonymous

2 Havoc.
About getting data from two or more table using join:
what you have said _IS NOT TRUE_. MySQL is faster than PGSQL in theese things 
as well, all depends on the type of join you use. If you select a correct join
 everything will work FASTER than PGSQL.
The only advantage of PG is full SQL'92 compliance (stored procs etc etc)

anonymous
()

2 anonymous: как я понял, ты фанат мускуля.
Поверь мне, я перепробовал не одну базу, и знаю, о чем говорю.
На более менее длинной выборке с объединением трех таблиц мускуль просто уходит в даун.

>Совсем празный вопрос: -В какой области нашей совковой
>жизнидеятельности возникают такие задачи, где объемы информации ?
>достигают сотни Гб и имеют столь сложную структуру. Ведь заводы и фабрики стоят?

В одесском порту гоняется лицензионный Оракл. Объем намного больше сотни гиг. Там даже стоит один из немногих AS/400 на Украине.

Havoc ★★★★
()
Ответ на: комментарий от Havoc

2 Havoc:
>>2 anonymous: как я понял, ты фанат мускуля. 
No, i am a fan of all that works good.
I also love Oracle but for most tasks it is way too big. 

>>Поверь мне, я перепробовал не одну базу, и знаю, о чем говорю. 
Well, what can i say....same here, same here. Though theese days i don't really have 
to check everything myself. We have a testing dept. here and they usually
do quite a job comparing different products of many different areas, 
 from compilers to DBMS.

>>На более менее длинной выборке с объединением трех таблиц мускуль просто уходит в
даун.
You need to optimize your tables or redezign the whole database.
Try using the explain command ...it will show you how the query works.

>>В одесском порту гоняется лицензионный Оракл. Объем намного больше сотни гиг. Там
даже стоит один из немногих AS/400 на Украине.
That's cool. People knew what they were doing :) ...Usually theese fuckheads 
in Europe use DB2 on AS/400 since its of the same company etc..

anonymous
()

Тебе чем то не нравится DB2 на AS/400?

Havoc ★★★★
()

Автору:
Везде, где есть системы координат, я бы использовал PostGreSQL - просто там есть тип "полигон" :)))))))
MySQL наверно у людей не валится. Вот только как хостинг-провайдер я знаю6 почему php скрипты пишут - "too many connections" вместо выборки из mysql.
А если снять лимит - прощай, VM.
reset только поможет.
Ну, на солярке это не надо, а линух точно валится.

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

No DB2 is quite OK, but Oracle is better, even folks from IBM now accept
 that fact (some of them) and in many cases their strataegy partners offer
 AS/400 + Oracle, not AS/400 + DB2....

AS/40 ...I just love it :)

anonymous
()

Hallo!

Ya kakto proboval na Postgresql vsyakie zaprosi po koordinatam...
Koroche nado yznat snachalo kakie SELECT ti budesh v bazu pichat!
Na nekotorie Postgresql mne takie Plani pisal ...... Primerno na sto
let ispilnenia. Tak esli chto to mailto:kred@akr.de


PS: Esli est dengi na ORACLE to ne dumai.
Do vstrech.

kred
()

А почему не информикс, скажем? :)

Havoc ★★★★
()
15 декабря 2001 г.

А с чего это вы взяли, что в mysql'е транзакции реалиизованы полноценно? - да, есть lock, но это немного не то, а точнее совсем не то. В результате корректно работает только lock с "w", что тоже не хорошо. Отсутствие полноценной реализации транзакций - вот одна из причин, по которой иногда mysql использовать нельзя.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.