«Камчатский форум» logo

Здравствуйте, гость ( Вход | Регистрация )

2 страниц   1 2 >   ( К первому непрочитанному сообщению )
Ответить · Открыть тему
> MySQL 4 VS MySQL 5
Kevin
15.03.2006, 18:36
Сообщение #1


*******
*******

Награды: 9
Группа: ????. ??????
Сообщений: 3 738
Регистрация: 02.04.2004

Репутация: 42 [ - / + ]


Насколько стабильна MySQL 5, и стоит ли переходить,
все же хранимые процедуры и триггеры очень заманчивы smile.gif

Или лучше пока сидеть на MySQL 4?
Офлайн · Карточка · Приват
^
Ilya V. Rudomilov
15.03.2006, 20:13
Сообщение #2


Путяра, пшёл вон!
*******

Награды: 9
Группа: ??????
Сообщений: 14 825
Регистрация: 30.03.2004

Репутация: 36 [ - / + ]


Цитата
Насколько стабильна MySQL 5, и стоит ли переходить,
все же хранимые процедуры и триггеры очень заманчивы smile.gif

Или лучше пока сидеть на MySQL 4?

У меня сейчас 5я версия стоит - вроде, довольно устойчива. По крайней мере, у меня проблем не возникает. Но, как я посмотрел, использование хранимых процедур не так удобно сделано, как хотелось бы.


--------------------
Обязательно к изучению - мой блог о моей жизни в Чехии! И хватит спрашивать "Почему же Чехия?.." - все ответы описаны уже.
Офлайн · Карточка · Приват
^
L@mer
15.03.2006, 20:31
Сообщение #3


Ветеран
******

Награды: 3
Группа: ??????
Сообщений: 1 368
Регистрация: 25.11.2005

Репутация: 20 [ - / + ]


У себя не серверах использую MySQL 4.1 полет нормальный, на одном uptime примерно 8 мес. второй недели две назад перезагружал. Но естествено сам мускул патченый мантейнером и обновляется регулярно. Пятерку даже не пробовал вот когда RH, Debian, её к себе в стабильный релиз положат тогда и будем переходить если понадобится. Но про нестабильность 5 ветки на форумах много говорят. На боевой сервак такое не ставят. А если серьёзно понадобился полноценный SQL сервер, то есть Postgres, кому нужны процедуры и триггеры его давно оседлали. Я бы на Postgres перешел давно, но у меня тулза одна есть так она заточена под мускул только недавно появилась поддержка PGS вот сейчас готовлю плавный переход. И вообще у PGS есть перспективы, 1С свой сервак 8 ветки на него будут вешать.
По скорости MySQL из-за простоты очень шустрый, что тоже не маловажно.
А есть еще Firebird(win,nix), так что не одним мускулом мир полнится


--------------------
Я бы изменил мир, но бог не дал исходников...
Изображение
Офлайн · Карточка · Приват
^
Kevin
15.03.2006, 20:58
Сообщение #4


*******
*******

Награды: 9
Группа: ????. ??????
Сообщений: 3 738
Регистрация: 02.04.2004

Репутация: 42 [ - / + ]


Просто MySQL идеально подходит для нужд веба, вот его и используем smile.gif
Офлайн · Карточка · Приват
^
L@mer
15.03.2006, 21:23
Сообщение #5


Ветеран
******

Награды: 3
Группа: ??????
Сообщений: 1 368
Регистрация: 25.11.2005

Репутация: 20 [ - / + ]


Цитата(Kevin @ 15.03.2006, 21:58)
Просто MySQL идеально подходит для нужд веба, вот его и используем smile.gif

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


--------------------
Я бы изменил мир, но бог не дал исходников...
Изображение
Офлайн · Карточка · Приват
^
Kevin
15.03.2006, 21:50
Сообщение #6


*******
*******

Награды: 9
Группа: ????. ??????
Сообщений: 3 738
Регистрация: 02.04.2004

Репутация: 42 [ - / + ]


В последнее время тоже смотрю в сторону PostgresSQL,
хотя MySQL вполне достаточно для веб нужд, а вот
хранимые процедуры в MySQL просто бальзам на душу
будут smile.gif
Офлайн · Карточка · Приват
^
L@mer
15.03.2006, 22:05
Сообщение #7


Ветеран
******

Награды: 3
Группа: ??????
Сообщений: 1 368
Регистрация: 25.11.2005

Репутация: 20 [ - / + ]


А что хочешь от процедур получить?


--------------------
Я бы изменил мир, но бог не дал исходников...
Изображение
Офлайн · Карточка · Приват
^
Kevin
15.03.2006, 22:35
Сообщение #8


*******
*******

Награды: 9
Группа: ????. ??????
Сообщений: 3 738
Регистрация: 02.04.2004

Репутация: 42 [ - / + ]


Цитата(LСобакаmer @ 15.03.2006, 23:05)
А что хочешь от процедур получить?

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

Соответственно, если делать хранимые
процедуры, то вся эта выборка уйдет от
РНР к самой базе денных.
Офлайн · Карточка · Приват
^
Screen
15.03.2006, 23:32
Сообщение #9


Заслуженный участник
*****

Награды: 3
Группа: ?????????
Сообщений: 991
Регистрация: 28.07.2005

Репутация: 8 [ - / + ]


В некоторых случаях вполне достаточно использовать [LEFT | INNER | RIGHT] join.

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


--------------------
Торговый бот для крипто биржи: https://fond.btc2yandex.com/
Обмен Bitcoin: https://btc2yandex.com/
Офлайн · Карточка · Приват
^
L@mer
15.03.2006, 23:38
Сообщение #10


Ветеран
******

Награды: 3
Группа: ??????
Сообщений: 1 368
Регистрация: 25.11.2005

Репутация: 20 [ - / + ]


В контексте твоей задачи вообще всю логику можно в процедуры загнать, php код куда стройней станет. Появляется новый аспект, взаимодействие с процедурами, но это уже техника, которую можно быстро освоить. Я например знаю реализацию системы биллинга на процедурах в Postgres, конечно не "мега стар", но подход интересен.
Да вопрос с java'ой работаешь? В контексте web приложений?


--------------------
Я бы изменил мир, но бог не дал исходников...
Изображение
Офлайн · Карточка · Приват
^
Kevin
15.03.2006, 23:52
Сообщение #11


*******
*******

Награды: 9
Группа: ????. ??????
Сообщений: 3 738
Регистрация: 02.04.2004

Репутация: 42 [ - / + ]


Screen, их пока и использовал, но жирными запросами
загромождать РНР тоже не очень верно, особенно если это
может делать БД, хочется делать все как можно более абстрактно.

LСобакаmer, можно, поэтому и интересуюсь пятой версией smile.gif
Очень удобно, SQL отделить от кода, как и HTML, и заниматься
только чистым программированием, а точнее посредничеством
между XML и БД smile.gif

Java пока не пользовался, но приглядываюсь, очень хороший язык,
уже в какой то теме высказывался, что хотелось бы со временем
перейти именно на него…
Офлайн · Карточка · Приват
^
Ilya V. Rudomilov
15.03.2006, 23:55
Сообщение #12


Путяра, пшёл вон!
*******

Награды: 9
Группа: ??????
Сообщений: 14 825
Регистрация: 30.03.2004

Репутация: 36 [ - / + ]


Цитата
В некоторых случаях вполне достаточно использовать [LEFT | INNER | RIGHT] join.

Слишком банально - думаю, здесь задача не в этом состоит.

Лично я переходить на хранимые процедуры планирую только с глобальным внедрением MySQL 5 на серверах хостера - пока его никуда не ставят, а посему и проект реализовать не получится. Хотя, подумываю о пробах пера на PostresSQL и Firebird - на сервере поддерживается, а для кругозора знать не помешает...


--------------------
Обязательно к изучению - мой блог о моей жизни в Чехии! И хватит спрашивать "Почему же Чехия?.." - все ответы описаны уже.
Офлайн · Карточка · Приват
^
L@mer
16.03.2006, 0:07
Сообщение #13


Ветеран
******

Награды: 3
Группа: ??????
Сообщений: 1 368
Регистрация: 25.11.2005

Репутация: 20 [ - / + ]


Поддерживаю Ilya V. Rudomilov в вопросе отсутствия MySQL 5 ветки пока в stable не перейдёт на боевых серваках никто ставить не будет.
А вот Postgres и Firebird уже сегодня реальны, и ИМХО ждать и время терять это не совсем правильно. Надо использовать все доступные возможности.


--------------------
Я бы изменил мир, но бог не дал исходников...
Изображение
Офлайн · Карточка · Приват
^
Ilya V. Rudomilov
16.03.2006, 0:16
Сообщение #14


Путяра, пшёл вон!
*******

Награды: 9
Группа: ??????
Сообщений: 14 825
Регистрация: 30.03.2004

Репутация: 36 [ - / + ]


Цитата
А вот Postgres и Firebird уже сегодня реальны, и ИМХО ждать и время терять это не совсем правильно. Надо использовать все доступные возможности.

А структуры запросов Postgres и Firebird сильно отличается от MySQL?


--------------------
Обязательно к изучению - мой блог о моей жизни в Чехии! И хватит спрашивать "Почему же Чехия?.." - все ответы описаны уже.
Офлайн · Карточка · Приват
^
L@mer
16.03.2006, 0:43
Сообщение #15


Ветеран
******

Награды: 3
Группа: ??????
Сообщений: 1 368
Регистрация: 25.11.2005

Репутация: 20 [ - / + ]


Postgres 7 ветка и Firebird полностью соответствуют стандарту SQL/92
MySQL 3 и 4 ветки ближе к стандарту SQL/89(в 4 он немного расширен)
MySQL 5 как в официале не знаю, но ИМХО думаю немного расширенный SQL/92, хотя вполне возможно и просто SQL/92.
SQL он и на Марсе SQL


--------------------
Я бы изменил мир, но бог не дал исходников...
Изображение
Офлайн · Карточка · Приват
^
Rownt
23.10.2008, 20:14
Сообщение #16


Учитель созерцания
*******

Награды: 7
Группа: ??????
Сообщений: 3 261
Регистрация: 04.04.2004

Репутация: 25 [ - / + ]


Реанимирую тему...smile.gif

Столкнулся с неожиданной для себя пролемой хранения в MySQL данных типа DATE.
Диапазон хранения данных тпа YEAR начинается с 1901 года. Все даты позапрошлого века при конвертировании в таблицу MySQL были преобразованы в 1970-01-01.
Как хранить события, которые произошли до 1901 года? А если хочется еще записать событие до нашей эры? Кто уже решал проблему?



--------------------
... сами не летаем и другим не дадим...:)

Камчатская студия дизайна Art Fashion Line
Офлайн · Карточка · Приват
^
psk
23.10.2008, 21:03
Сообщение #17


Заслуженный участник
*****

Награды: 4
Группа: ??????
Сообщений: 769
Регистрация: 09.11.2005

Репутация: 6 [ - / + ]


Цитата(Rownt @ 23.10.2008, 22:14)
Как хранить события, которые произошли до 1901 года?

В DATE может хратиться диапазон от 1000-01-01 до 9999-12-31. YEAR, соотвесттвенно, вам не подходит.
А хранить придется просто в строке (VARCHAR).. или чем не устраивает?


--------------------
Господи правый, пошли нам прозрения час
Офлайн · Карточка · Приват
^
Rownt
23.10.2008, 22:21
Сообщение #18


Учитель созерцания
*******

Награды: 7
Группа: ??????
Сообщений: 3 261
Регистрация: 04.04.2004

Репутация: 25 [ - / + ]


Цитата(Paskam @ 23.10.2008, 22:03)

А хранить придется просто в строке (VARCHAR).. или чем не устраивает?

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


--------------------
... сами не летаем и другим не дадим...:)

Камчатская студия дизайна Art Fashion Line
Офлайн · Карточка · Приват
^
psk
23.10.2008, 23:37
Сообщение #19


Заслуженный участник
*****

Награды: 4
Группа: ??????
Сообщений: 769
Регистрация: 09.11.2005

Репутация: 6 [ - / + ]


Цитата(Rownt @ 24.10.2008, 0:21)
Усложняет функционал до не приличия. В программе идут различные вычисления: определение текущей даты, разности дат и пр... Иными словами, все равно придется преобразовывать тип данных...

Ну если от 1000-01-01 до 9999-12-31 не устраивает, но предположу что в MySQL нет таких средств (по крайней мере в документации этого нет), т.е. придется расчитывать это в самом приложении. Может кто поправит..
А интересно, что за задача, где нужны такие диапазоны дат?


--------------------
Господи правый, пошли нам прозрения час
Офлайн · Карточка · Приват
^
Stigma
24.10.2008, 5:00
Сообщение #20


Постоянный посетитель
***

Группа: ?????????
Сообщений: 188
Регистрация: 07.03.2008

Репутация: 5 [ - / + ]


Цитата(Rownt @ 23.10.2008, 23:21)

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

ну вроде str_to_date() делает из varchar обычную date, которая спокойно обрабатывается стандартными фукнциями в рамках запроса, типа этого:
SELECT datediff(str_to_date(da1,'%d/%m/%Y'), str_to_date(da2,'%d/%m/%Y')) FROM da
Или речь о чем-то другом?
Если об этом, то и проблема эры решается аналогично в одном запросе, только нужно еще анализировать состояние флажка хранящего соответствующий признак, да код подлиннее.

Сообщение отредактировал Stigma - 24.10.2008, 5:44
Офлайн · Карточка · Приват
^

2 страниц   1 2 >
Ответить · Открыть тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



Код кнопки 88x31 Текстовая версия Русская версия Invision Power Board v2.1.7 © 2006  IPS, Inc.