MyISAM vs InnoDB

Подниму ка я здесь эту извечную тему. Итак, MyISAM плюсы:

- ест меньше памяти

- говорят что быстрее на инсертах, селектах и делитах

- таблицы занимают меньше места на диске

- вроде как лудше на растущем количестве одновременных запросов

InnoDB плюсы:

- говорят что быстрее на апдейтах

- вот здесь http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-ben... написано что быстрее на большинстве тестов

- лочит строку а не всю таблицу

- надежнее востанавливается после сбоев

- хот бекап таблиц

А вы что думаете? Что выбирать?

ИнноДБ - транзакционный движок.
А вообще, неужели трудно зайти на сайт МуСкуля, и почитать ?

Да, про транзакции как то вылетело из головы. А на сайт я заходил и читал конечно же.

зависит от типа задач (какие операции доминируют), например для форумов однозначно MyISAM

не стоит перечислять громкие эпитеты про память, место и тд... здесь, принципиальное понимание - транзакционность. мускуль - записная книжка с поддержкой SQL языка. Потом была попытка зделать из этой книжечки боле-менее внятное СУБД, добавив поддержку транзакций - иннодб. разумеется любое добавление функциональности влечет за собой затраты по ресурсам.

Инструмент выбирают исходя из задачи. Озвуч ее плиз.

выбирай postgres :)

там где нужен MyISAM - там и SQLite сгодится =)

а вообще тут уже говорили про то что зависит от задачи и предпологаемой нагрузки.

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

а язык программирования php?

ЗЫ на днях одного человека таки убедил что лучше один крутой спец чем три студента. Суть в том что эти три студента, помимо того что всё время упираются в трудности которые они долго и упорно преодолевают, некоторые куски кода переписывали многократно по мере роста нагрузки. Сами понимаете что втроём они сделали работы не больше чем один бы опытный чувак за это время. Ну и руководить тремя прогерами раз в пять сложнее чем одним(их надо между собой координировать). Это так, лирическое отступление, не знаю зачем это написал.

А ты никогда не был студентом? Наверно родился сразу крутым спецом. Где бы ты сейчас был, если бы все думал как и ты?

> ЗЫ на днях одного человека таки убедил что лучше один крутой спец чем три студента. Суть в том что эти три студента, помимо того что всё время упираются в трудности которые они долго и упорно преодолевают, некоторые куски кода переписывали многократно по мере роста нагрузки. Сами понимаете что втроём они сделали работы не больше чем один бы опытный чувак за это время. Ну и руководить тремя прогерами раз в пять сложнее чем одним(их надо между собой координировать). Это так, лирическое отступление, не знаю зачем это написал.

http://qnx.org.ru/forum/index.php/topic,544.msg8298.html#msg8298

--- cut ---
Любой русский программист после пары минут чтения кода, обязательно вскочит и произнесет обращаясь к себе: переписать это все нафиг. Потом в нем шевельнется сомнение в том, сколько времени это займет, и остаток дня русский программист потратит на то, что будет доказывать самому себе, что это только кажется, что переписать это много работы. А если взяться и посидеть немного, то все получится. Зато код будет красивый и правильный. На следующее утро русский программист свеж, доволен собой и без единой запинки докладывает начальству, что переписать этот кусок займет один день, не больше. Да, не больше. Ну, в крайнем случае, два, если учесть все риски. В итоге начальство даст ему неделю и через полгода процесс будет успешно завершен. До той поры, пока этот код не увидит другой русский программист.

А в это время, в соседних четырех кубиках, будет ни на секунду не утихать работа китайских программистов, непостижимым образом умудряющихся прийти раньше русского программиста, уйти позже, и при этом сделать примерно втрое меньше. Эта четверка, давно не пишет никакого кода, а только поддерживает код написанный, в свое время индусом и дважды переписанный двумя разными русскими. В этом коде не просто живут баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при помощи любимой китайской технологии реиспользования кода - copy/paste. Отсюда баги расползаются в разные стороны посредством статических переменных и переменных переданных по ссылке (поскольку, китайский программист не может смириться с неудобствами вызванными тем, что он не может изменить значение внешней переменной переданной в его функцию модулями, которые переписывает русский программист).

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

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

О, канадский программист это особый тип. Он ни на минуту не задумываясь, как рыцарь без страха и упрека, бросится чинить самый свирепый баг китайского кода. Этот Баг живет там уже три года, и китайцы уже четырежды (каждый по разу) сообщали начальству, что он починен. Но Баг каждый раз возвращался, как Бетмен в свой Готхем. Итак, канадский программист сделает то, чего китайцы не рисковали делать в течении трех долгих лет. Он, при помощи дебагера, отследит место, где статическая переменная приняла значение -1 вместо правильного 0, и решительным движением заведет рядом вторую переменную с правильным значением. Баг погибнет в неравной схватке с канадским программистом. Но победа будет достигнута тяжелой ценой.

Работать перестанет все, включая только что переписанный русским программистом код. Это повергнет русского программиста в задумчивость на целых два дня, после чего он сделает, в общем-то, предсказуемый вывод о том, что дизайн с самого начала был неправильным, и все надо переписать. На это нам нужна неделя. Да, неделя, не больше. Канадский программист смело бросится налаживать все, и станет еще хуже, хотя казалось бы... Эта суета выведет из медитации индуса, который придумает и вовсе гениальное решение - отбранчить код. Согласно его плану, мы теперь будем поддерживать две версии одного и того же кода - одну работающую но с Багом, другую без Бага, но не работающую. Русский программист услышав об этом плане, сломает линейку об стол и дома обзовет жену дурой, но на митинге возразить не решится.

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

// wbr

Руководитель проекта должен думать как ему проект побыстрее и покачественнее сделать а не где сэкономить на персонале. Вот и всё что хотел своими словами сказать. Безусловно, когда выбираешь распространённую технологию людей найти легке.

Что делать тем кто начинает "с нуля" на лоре писалось не раз. Я, например, придумываю ТЗ какое-нить реальное средней сложности и начинаю его делать чтобы получился "реальный" опыт. Пара месяцев погружения "с головой" и уже неплохие результаты. Хотя, по моим наблюдением, обычно пол года требуется чтобы "втянуться", узнать best practices итп. ну и в реальности, как правило, всё сложнее чем при самоподготовке.

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

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

Теперь я с тобой согласен. Просто твой первый пост на эту тему имел несколько иную окраску.