-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Использует ли кто нибудь транзакции в MySQL?
- Автор темы Romantik
- Дата начала
Апельсин
Оранжевое создание
> Ваше мнение я бы и хотел услышать, уважаемая.
> Почему InnoDB ?
> Как давно?
используем где-то с января или февраля месяца
почему так?
Я в это время пришла на фирму, т.е. появился человек для которого занятие MySQLем стало "основным" занятием
кроме того InnoDB/MySQL где-то в это время стало stable
что касается Berkley .. ну мы для себя делали тесты на разных таблицах и BDB себя не очень хорошо показала :-( на не маленьком DELETE зависло вообще .. пнули MySQL AB они сказали, что будут все это лечить путем апгрейда BDB, т.к. то что сейчас идет вместе с мусклем - устаревшее .. Так что надо будет посмотреть потом еще раз на BDB
кроме того мне интересно было поработать с foreign key
собственно это тоже сыграло значительную роль.
> И какие глюки былы при разработке таблиц, их модификации и собственно использования?
занимает на много больше места чем MyISAM таблица.
Долго работает SELECT COUNT(*)
были проблемы из-за неумелого пользования некоторых особ с которыми я работаю особенно InnoDB+репликация ..
> Почему InnoDB ?
> Как давно?
используем где-то с января или февраля месяца
почему так?
Я в это время пришла на фирму, т.е. появился человек для которого занятие MySQLем стало "основным" занятием
кроме того InnoDB/MySQL где-то в это время стало stable
что касается Berkley .. ну мы для себя делали тесты на разных таблицах и BDB себя не очень хорошо показала :-( на не маленьком DELETE зависло вообще .. пнули MySQL AB они сказали, что будут все это лечить путем апгрейда BDB, т.к. то что сейчас идет вместе с мусклем - устаревшее .. Так что надо будет посмотреть потом еще раз на BDB
кроме того мне интересно было поработать с foreign key
собственно это тоже сыграло значительную роль.
> И какие глюки былы при разработке таблиц, их модификации и собственно использования?
занимает на много больше места чем MyISAM таблица.
Долго работает SELECT COUNT(*)
были проблемы из-за неумелого пользования некоторых особ с которыми я работаю
особенно InnoDB+репликация .. Romantik
TeaM PHPClub
воот, а я попал с BDB и очень хорошо 
причем на начальной разработке- ну думал при модификации глючит- фиг с ним.... работает же...
А вот пару недель назад началось переполнение лог.отката и клюки с потерей данных. Хотя мож и я "особа, которая неумело пользуется" , почему и создал опрос и хочу поспрашивать знатоков.
перевести множество программ терь ох как сложно. Но все же нужно. Вы сможете мне в этом помочь ? В частности с практической работой. Обещаю не сильно доставать
причем на начальной разработке- ну думал при модификации глючит- фиг с ним.... работает же...
А вот пару недель назад началось переполнение лог.отката и клюки с потерей данных. Хотя мож и я "особа, которая неумело пользуется"
, почему и создал опрос и хочу поспрашивать знатоков.перевести множество программ терь ох как сложно. Но все же нужно. Вы сможете мне в этом помочь ? В частности с практической работой. Обещаю не сильно доставать
Апельсин
Оранжевое создание
> >занимает на много больше места чем MyISAM таблица.
> ну это не критично....
ну как тебе сказать ..
примерная формула конфертации из MyISAM в InnoDB
1.5*(размер .MYD) + 5*(размер .MYI)
но в реальности у нас даже больше получалось .. :-(
не критично, но тем не менее ..
+ логи ..
> это InnoDB ?
да
> почему и собираются ли фиксить - не спрашивали ?
потому что в MyISAM число строк храниться, а в InnoDB каждый раз считается по новой
SHOW TABLE STATUS показывает только приблизительное число строк..
ну как бы в TODO оно есть, но насколько оно приоритетно я не знаю.
> ну это не критично....
ну как тебе сказать ..
примерная формула конфертации из MyISAM в InnoDB
1.5*(размер .MYD) + 5*(размер .MYI)
но в реальности у нас даже больше получалось .. :-(
не критично, но тем не менее ..
+ логи ..
> это InnoDB ?
да
> почему и собираются ли фиксить - не спрашивали ?
потому что в MyISAM число строк храниться, а в InnoDB каждый раз считается по новой
SHOW TABLE STATUS показывает только приблизительное число строк..
ну как бы в TODO оно есть, но насколько оно приоритетно я не знаю.
Вряд ли получится это пофиксить. InnoDB --- версионник, потому обязан при SELECT count(*) сканировать всю таблицу.
Не флейму ради (хе-хе), а любопытства здорового для: что заставляет использовать MySQL+InnoDB, которому без году неделя и hot backup для которого стоит денег, вместо PostgreSQL (или уж Firebird), где версионный движок отшлифован годами использования, hot backup бесплатный, да и возможности SQL гораздо более богатые?
Апельсин, ты же уже большая девочка и --- я верю --- можешь написать более аргументированный ответ. 
Это было бы замечательным ответом, если бы я спросил: "А почему ты играешь в Warcraft 3 за эльфов ночи, а не за орков?"
А это не аргументация, а констатация факта. Что именно заставило вашу фирму и ваших клиентов выбрать MySQL (вернее, именно MySQL+InnoDB)? Мне правда интересно.3. политика фирмы.
4. наши клиенты используют/хотят использовать MySQL, дальше см. пункты 1, 2, 3
Romantik
TeaM PHPClub
Последний аргумент, который меня выбилс BDB- это когда все же база запустилась, с потерянными данными, она(база) ТУПО перестала писать в себя и тем более выдавать ошибки!
Когда я это обнаружил- прошло время.
Выход был смешной изменил тип на MyISAM и потом обратно BDB.
НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛЬЗУЙТЕ BDB!!!!!!!!!!!!
Хотя, год работало нормально!
Когда я это обнаружил- прошло время.
Выход был смешной изменил тип на MyISAM и потом обратно BDB.
НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛЬЗУЙТЕ BDB!!!!!!!!!!!!
Хотя, год работало нормально!
tony2001
TeaM PHPClub
Sad Spirit:
недавно решил немного в Постгресе разобраться, почитал ман, примеры посмотрел...
там, конечно, очень много вкусностей реализовано.
НО!
для того, чтобы с ней реально работать - мне надо убить не одну неделю времени просто "на разобраться".
а MySQL реально проще в 90% случаев.
тем более, что ВСЕ возможности Постгреса не нужны мне (и видимо клиентам Апельсин), нужны только некоторые фичи.
если можно заменить Постгрес малой кровью - они (и я) заменяют.
недавно решил немного в Постгресе разобраться, почитал ман, примеры посмотрел...
там, конечно, очень много вкусностей реализовано.
НО!
для того, чтобы с ней реально работать - мне надо убить не одну неделю времени просто "на разобраться".
а MySQL реально проще в 90% случаев.
тем более, что ВСЕ возможности Постгреса не нужны мне (и видимо клиентам Апельсин), нужны только некоторые фичи.
если можно заменить Постгрес малой кровью - они (и я) заменяют.
Апельсин
Оранжевое создание
> можешь написать более аргументированный ответ.
он вполне аргументирован То что является весомым аргументом для меня, может и не быть таковым для тебя :-Р
тем более что я не собираюсь тебя или еще кого-то переубеждать
> Это было бы замечательным ответом, если бы я спросил: "А почему ты играешь в Warcraft 3 за эльфов ночи, а не за орков?"
Если я что-то знаю хорошо, то я могу предложить _хорошее_ решение с использованием данных средств (это не значит что я считаю MySQL универсальным решением для всех задач).
В последнее время там появилось много нового и интересного для меня и мне интересно с этим разбираться. За тот последний год, когда мне пришлось очень активно столкнуться с MySQLем, разочаровываться в нем мне пока не пришлось
С теми задачами, для которых мы его использовали он отлично с ними справляется. После перевода части серверов на 4.0, которая декларируется как beta, он забегал еще быстрее.
> Что именно заставило вашу фирму и ваших клиентов выбрать MySQL (вернее, именно MySQL+InnoDB)?
мой шеф - фанат Linux'а и MySQL'я Это наложило свой отпечаток на выбор СУБД. Что касается InnoDB - нужны были транзакции, that's all. Почему не BDB - я писала выше.
он вполне аргументирован
То что является весомым аргументом для меня, может и не быть таковым для тебя :-Ртем более что я не собираюсь тебя или еще кого-то переубеждать
> Это было бы замечательным ответом, если бы я спросил: "А почему ты играешь в Warcraft 3 за эльфов ночи, а не за орков?"
Если я что-то знаю хорошо, то я могу предложить _хорошее_ решение с использованием данных средств (это не значит что я считаю MySQL универсальным решением для всех задач).
В последнее время там появилось много нового и интересного для меня и мне интересно с этим разбираться. За тот последний год, когда мне пришлось очень активно столкнуться с MySQLем, разочаровываться в нем мне пока не пришлось
С теми задачами, для которых мы его использовали он отлично с ними справляется. После перевода части серверов на 4.0, которая декларируется как beta, он забегал еще быстрее.
> Что именно заставило вашу фирму и ваших клиентов выбрать MySQL (вернее, именно MySQL+InnoDB)?
мой шеф - фанат Linux'а и MySQL'я
Это наложило свой отпечаток на выбор СУБД. Что касается InnoDB - нужны были транзакции, that's all. Почему не BDB - я писала выше.Реально проще? То, что можно реализовать в большинстве баз на уровне СУБД её же средствами (процедурные языки, проверка целостности, триггеры) в MySQL придётся реализовывать в (нетривиальном) клиентском коде. Если клиентов много (web и "толстый" клиенты), то N раз.
Так речь идёт не о "замене Постгреса" а об изначальном выборе СУБД. Просто MySQL+InnoDB позиционируется как вещь для mission-critical приложений, а не страниц Вась Пупкиных. В этом секторе есть как минимум два (или три, + SAP DB) свободных конкурента с гораздо более богатыми возможностями.
Пока я услышал только одну причину выбора: лень учиться. Хотя причина и безусловно, важная, но как-то гложут меня всё ещё сомнения...
tony2001
TeaM PHPClub
>Реально проще? То, что можно реализовать в большинстве баз
>на уровне СУБД её же средствами (процедурные языки,
>проверка целостности, триггеры) в MySQL придётся
>реализовывать в (нетривиальном) клиентском коде. Если
>клиентов много (web и "толстый" клиенты), то N раз.
да.
то, что МНЕ надо - реально проще.
>Так речь идёт не о "замене Постгреса" а об изначальном
>выборе СУБД. Просто MySQL+InnoDB позиционируется как
>вещь для mission-critical приложений, а не страниц Вась
>Пупкиных. В этом секторе есть как минимум два (или три, +
>SAP DB) свободных конкурента с гораздо более богатыми
>возможностями.
я очень рад, что они есть.
значит есть свобода выбора.
я выбрал то, что я выбрал.
у тебя есть претензии ко мне по этому поводу?
>Пока я услышал только одну причину выбора: лень учиться.
>Хотя причина и безусловно, важная, но как-то гложут меня
>всё ещё сомнения...
эта тирада напоминает мне:
ты знаешь китайский ? только английский ?
странно. почему ?
он намного круче, там столько букв!
он настолько богаче ?
а...лень учить...
Я уважаю твои знания в Постгресе.
Я уважаю сам Постгрес.
Но если он мне не нужен - я его не использую.
з.ы. поменяй, плз, закрывающий тэг в подписи на открывающий - будет честнее.
>на уровне СУБД её же средствами (процедурные языки,
>проверка целостности, триггеры) в MySQL придётся
>реализовывать в (нетривиальном) клиентском коде. Если
>клиентов много (web и "толстый" клиенты), то N раз.
да.
то, что МНЕ надо - реально проще.
>Так речь идёт не о "замене Постгреса" а об изначальном
>выборе СУБД. Просто MySQL+InnoDB позиционируется как
>вещь для mission-critical приложений, а не страниц Вась
>Пупкиных. В этом секторе есть как минимум два (или три, +
>SAP DB) свободных конкурента с гораздо более богатыми
>возможностями.
я очень рад, что они есть.
значит есть свобода выбора.
я выбрал то, что я выбрал.
у тебя есть претензии ко мне по этому поводу?
>Пока я услышал только одну причину выбора: лень учиться.
>Хотя причина и безусловно, важная, но как-то гложут меня
>всё ещё сомнения...
эта тирада напоминает мне:
ты знаешь китайский ? только английский ?
странно. почему ?
он намного круче, там столько букв!
он настолько богаче ?
а...лень учить...
Я уважаю твои знания в Постгресе.
Я уважаю сам Постгрес.
Но если он мне не нужен - я его не использую.
з.ы. поменяй, плз, закрывающий тэг в подписи на открывающий - будет честнее.
Почему не BDB понятно. Вопрос в другом, почему не PostgreSQL или Firebird? Или ничего кроме MySQL просто не рассматривалось?
Апельсин
Оранжевое создание
> Просто MySQL+InnoDB позиционируется как вещь для mission-critical приложений
не всегда нужны триггеры и хранимые процедуры.
там где я использую MySQL - они не нужны.
если кому-то они нужны - пусть выбирают другую СУБД, я уже говорила, что никого не агитирую.
> Просто MySQL+InnoDB позиционируется как вещь для mission-critical приложений
мне нравиться использовать InnoDB в случае одновременных SELECT+UPDATE
> Пока я услышал только одну причину выбора: лень учиться.
хехе
с удовольствием учусь
вот пинаю шефа, что бы MySQL 4.1. поставить поковыряться
не всегда нужны триггеры и хранимые процедуры.
там где я использую MySQL - они не нужны.
если кому-то они нужны - пусть выбирают другую СУБД, я уже говорила, что никого не агитирую.
> Просто MySQL+InnoDB позиционируется как вещь для mission-critical приложений
мне нравиться использовать InnoDB в случае одновременных SELECT+UPDATE
> Пока я услышал только одну причину выбора: лень учиться.
хехе
с удовольствием учусь
вот пинаю шефа, что бы MySQL 4.1. поставить
поковыряться