Вопрос по базам

Залез я в глубины программирования и проектирования и возник такой вопрос.

Что лучше использовать MyISAM или InnoDB? Всю жизнь везде юзал MyISAM. Да и в yii реализована “поддержка внешних ключей” relations.

Кто что использует и по каким причинам? Из лазанья по инету нашел только следующее:

innodb транзакционный движок, запись происходит немного медленне чем в myisam, но чтение быстрее. и не будет проблем с одновременным доступом/блокированием записей. из плюсов еще поддержка внешних ключей, но с использованием yii - нужно ли это вообще?

Зависит от проекта и требований к нему. Я использовал и то и то в свое время для разных проектов

http://programmersno…nodb-vs-myisam/

Вот только модератор этого форума у себя опубликовал пост. Конечно, на буржуйском, но если с ним знаком - то всё хорошо.

Но общая мысль уже была выражена, InnoDB - транзакции, защита получше, запись из-за этого чуть помедленнее; MyISAM - для блогов ;)

В общем, если не рассчитывается, что в базу будет лезть одновременно сразу множество клиентов с попытками записи или правки уже существующих в ней данных, то - MyISAM.

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

Планируется сайт типа нонейма :) наверно лучше MyISAM поставить и не заморачиваться

для меня критерием выбора является “навороченность” структуры самой базы для проекта. если до 10 таблиц в базе то можно MyISAM, но если нужна бизнес логика на уровне базы, то InnoDB или воопче другая база. не будем забывать что mySQL это попытка заполнить некоторые пробелы примитивной базы mSQL. имиенно потому релизовывать бизнес логику на mySQL сложнее. некоторые фишки не работают как должно.

для интернет проектов 99% у меня MyISAM. пока никто не жаловался.

Юзайте постгрес или оракл - и не будете знать проблем :)

Quote

link=topic=2273.msg12589#msg12589 date=1242977404]

Юзайте постгрес или оракл - и не будете знать проблем :)

хорошоие базы. у меня знакомые делали проект “кондитерские рецепты” для небольшой пекарни, в базе около 12-и таблиц. использовали постгрес. но дистрибутив около 100 Мб на диске и база предназначена для хранения астрономических массивов. :) када я спросил о выборе базы, просто они уже знают эту базу. сильный аргумент.

када я выбираю базу то стараюсь опираться на это:

  1. назначение базы

  2. возможности

  3. простота администрирования (например, для Oracle нужен админ базы)

Если нужно что-то по-проще, то MyISAM.

Если же не боишься заморочек, то InnoDB.

К примеру, magento магазин требует innodb. Я вообще не знал о существовании innodb в течение первых двух лет работы на php, и при этом в портале более 60-ти таблиц.

IMHO, одной из главных особенностей innodb это ключи, но именно поэтому даже экспорт/импорт базы усложняется.

ну естественно для сайта везитки использовать постгрес я не предлагаю.

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

Достаточно сложно для простого интернет проекта определиться с базой. У меня есть хороший опыт работы с ораклом (в банке 3 года и сейчас в компании PHP+oracle), но оракл не поставишь на сайт - слишком требовательна к ресурсам… в будущем вполне возможно, когда сайт разовьется - перейду на оракл…

Сейчас у меня вопрос стоит не по части построения логики на базе. Если преимущество InnoDb над myisam только в ключах и транзакциях - то лучше я заюзаю myisam, т.к. relations yii и без innodb умеет делать, а транзакции… вот скажите - где в новостном сайте их использовать? это скорее для крупных проектов где важна защита, стабильность и т.д. (п.с. за 7 лет работы с базами - ни разу ничего в них не терял)

Если проект в виде блога или просто cms-ка сайта - тогда транзакции ну в принципе некто не использует. но если вы пишите интернет аукцион к примеру где пользователи 100% будут посылать кучу запросов к одной таблице - тогда уж без транзакций тут не как.

Ну это не совсем “просто кмс-ка”, да и не блог… но смысл я понял, спс :)

Я в шоке… утверждение - “для разных проектов использую разные бд” - это круто… парни, либо вы не хилые знатоки тонкостей оптимизации запросов и проектирования схемы различных субд, либо глупостями занимаетесь - типа, если в оракле сделать абсолютно такую же структуру таблиц, работать лучше будет - это же оракл :)

“вещи посерьезнее чем мускул” :) т.е. берем постоянно развивающийся yii, которому от роду без году неделя, и пишем на нем приложение, для которого не хватит возможностей мускула, поэтому будем прикручивать каше :) причем не хватит пятого мускула, с транзакциями, вьюхами, триггерами и т.д. :) а вот глупые дядьки из того же knowledgetree почему-то пишут свои системы используя мускул и не стремятся к более навороченным субд.

PS: не хочу никого обидеть, если вдруг кого задело - извиняйте, я без зла. Но обидно как-то за мускул :) лет 8 назад - да, не было вариантов, пришлось для полноценного решения задачи с него уползать на fireird, но тогда был 3 мускул и никакой конкуренции файерберду, даже первому, он составить не мог…

to dikoy

людям которые не знают тонкастей оракла и постгерса не понять почему мускул является приметивной БД (да, да, пятая версия в том числе!). Почему то интересно гугл, яндекс, рамблер - не используют мускул. Интересно почему? (да, да, даже пятую версию с супер приметивными тригерами и прочими функциям) Конечно же потомучто они плохо вникли в тонкости оптимизации запросов mysql и решили выпендрится и сразу перешли на чтото "менее крутое и функциональное" чем mysql5. но конечноже у нас knowledgetree в приоретете и будем ровняться на него

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

MySQL безусловно легче, именно поэтому её логичнее использовать на простых сайтах которые не требуют на себя большой нагрузки и ресурсов самой базы. К примеру я сейчас пишу городской портал недвижимости где используются и тригеры, и хранимые процедуры, и ltree (о котором мускул только мечтает), массивы внутри ячеек разных типов, предполагаемый размер базы данных за первый год работы проекта >1TB. Так что если я начну делать этот проект на мускуле - я буду выглядеть круглым идимотом который думает что мускул спасет мир и круче мускула ничего нету. при том такого функционала который мне дает постгрес - мускул думаю и в 6й ветке не даст.

Короче если кого обидел, тоже извените. но ИМХО уже накипело слушать людей которые возносят mysql до хз каких высот обосновывая это только тем что им пользуеться фирма1, фирма2 и тп. какая разница кто им пользуется, для разных целей надо подбирать соотвествующюю базу данных. Тоже самое и с программированием. Не для всех задач лучшим решением будет PHP, к примеру гдето надо и Perl применить. А там где perl непойдет, может и tcl будет лучшим решением. И тут уже ненадо как баран уператься мол я использую mysql - он подойдет для всех задач. На одной технологии жизнь незаканчивается, и если вы выучили только mysql/php и применяете их - мне вас искренне жаль, т.к. вы уже давно не развиваетесь как программист.

Quote

link=topic=2273.msg12733#msg12733 date=1243158955]накипело слушать людей которые возносят mysql до хз каких высот

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

пердставьте вебсервер на котором около 1000 сайтов и приблиз. столько же баз даных. или часто посещаемый портал. тут без mySQL ну никак. это и есть основное назначение mySQL

ну поскольку пошел деловой базар, то предлагаю вашему вниманию еще одного “гуся” http://www.intersystems.com/cache/

Quote

link=topic=2273.msg12733#msg12733 date=1243158955]

Короче если кого обидел, тоже извените. но ИМХО уже накипело слушать людей которые возносят mysql до хз каких высот обосновывая это только тем что им пользуеться фирма1, фирма2 и тп. какая разница кто им пользуется, для разных целей надо подбирать соотвествующюю базу данных. Тоже самое и с программированием. Не для всех задач лучшим решением будет PHP, к примеру гдето надо и Perl применить. А там где perl непойдет, может и tcl будет лучшим решением. И тут уже ненадо как баран уператься мол я использую mysql - он подойдет для всех задач. На одной технологии жизнь незаканчивается, и если вы выучили только mysql/php и применяете их - мне вас искренне жаль, т.к. вы уже давно не развиваетесь как программист.

Тронуло, аж до слез!!

Согласен полностью!

Quote

link=topic=2273.msg12733#msg12733 date=1243158955]

to dikoy

…skipped…

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

сорри, но, imho, это высказывание чушь. если Вы, уважаемый (без тени усмешки) Zolter, действительно в тонкостях разбираетесь и в оракле и в постгресе и в мускуле честь и хвала, а если это высказывание основано на общих принципах оптимизации join'ы тормозят выполнение запроса, искуственные ключи лучше чем естественные, то пердыдущее высказывание чушь.

Quote

Поэтому тем кто прочитал в своей жизне пару книжек >500стр. по оптимизации и проектированию БД - понятны все эти тонкости без проблем.

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

Кстати, можно погуглить на предмет стоимости специальных курсов по оптимизиции БД того же оракла, IB/FB, не знаю есть-ли по постгресу, посмотреть на цену и понять, что читать книжку стоимостью раз в 100-200 меньше, наверное, не то же самое… хотя, как обычно, стоимость курсов наверняка весьма завышена от КПД :)

Quote

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

опять чушь, легче чего мускул? легче воздуха и взлетает? что значит большая нагрузка - ведро воды что-ли на него ставят? нагрузка на железо на котором работает Ваша СУБД. Как можно оценивать нагрузку на БД. Ну висит у меня сайт с посещаемостью 20 млн чел. в день и 500 запросами на одну страницу на кластере общим числом процессоров 512, все 3Ггц  Xeon'ы восьмиядерные, и терабайтом оперативной памяти ну и что? ни один пользователь не заметит тормозов, даже если я криво спроектирую базу и буду использовать вложенные select'ы повсеместно.

Quote

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

портал на yii пишется? (даже боюсь услышать положительный ответ :) хотя, почему бы и нет, можно ведь и from scratch написать :) размер бд больше терабайта?  :o думается мне однозначно реинжиниринг бд и всего приложения :) как минимум перестать хранить в бд ежедневноый своп от винды :)

Quote

Так что если я начну делать этот проект на мускуле - я буду выглядеть круглым идимотом который думает что мускул спасет мир и круче мускула ничего нету. при том такого функционала который мне дает постгрес - мускул думаю и в 6й ветке не даст.

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

Quote

Короче если кого обидел, тоже извените. но ИМХО уже накипело слушать людей которые возносят mysql до хз каких высот обосновывая это только тем что им пользуеться фирма1, фирма2 и тп. какая разница кто им пользуется,

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

Quote

для разных целей надо подбирать соотвествующюю базу данных. Тоже самое и с программированием. Не для всех задач лучшим решением будет PHP, к примеру гдето надо и Perl применить. А там где perl непойдет, может и tcl будет лучшим решением. И тут уже ненадо как баран уператься мол я использую mysql - он подойдет для всех задач.

при правильном применении мускул подойдет для решения любой задачи. это я как раз уперся :) но, тем не менее, считаю - специалист в узкой области всегда будет в этой области лучше чем три широкопрофильных специалиста. один человек не может знать все. но уж если на то пошло - если вдумчиво вчитаться в первый пост мы поймем - нету ни перла, ни тисиэля, даже захудалого питона и того нету. Есть yii (а с ним php) и есть вопрос про myisam и innodb.

Лет 10 назад писал интернет магазин для конторы в которой работал. Ну как же - интернет магазин, там все по взрослому - конечно firebird. Как может мускул справиться, там ведь куча всяких обработок, связанных атрибутов и прочей фигни, я уж сейчас и не вспомню. О том как ставили фаерберд на хостинг и пересобирали php вообще отдельная история. А где-то через год вышел oscommerce на мускуле, кривой он правда был, но при некотором допиливании делал то же самое, что и мой супернаворочанный на жар-птице. так что все дело в разработчике и его знании инструмента которым он пользуется - можно и на одной струне скрипки сыграть так, что симфонический оркестр обзавидуется.

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

Quote

На одной технологии жизнь незаканчивается, и если вы выучили только mysql/php и применяете их - мне вас искренне жаль, т.к. вы уже давно не развиваетесь как программист.

если вы выучили все что можно, с большой долей вероятности, вы не сможете ничего.

развиваться как известно можно либо вверх, либо вширь… Вы предлагаете развитие вширь…

а теперь далее, господа, вот честное слово, просвятите меня горемычного - либо у вас времени валом изучать досконально (в противном случае вообще не смысла изучать) субд которую не знаете, либо проекты у вас такие, что дедлайн через полгода, и то если дождя не будет, читай опять же времени валом. либо вы считаете, что книжка за 500 рублей сделает из вас специалиста?

15 лет программирую, а вот как-то не постиг в деталях кучу языков и технологий. Все как-то сходится к простым вещам - простой проект одна технология, сложный проект другая - и все, нету еще 20 в загашнике. языков знаю (не в плане синтаксиса, а в плане максимального использования возможностей и библиотек) - 3, и из СУБД хорошо знаком только с мускулом и фаербердом - потому как больше не надо было. Хотя и с ораклом сталкивался и с постгресом и с субейзом и с дб2, но не знаю я их - когда-то что-то изучал, но это все забывается еще быстрей чем волосы выпадают - могу чего-нибудь в них сделать, но по моим понятиям это не серьезно - использовать субд с кучей возможностей и не уметь ими пользоваться - лучше уж через известно что на мускуле, а чтобы изучить, протестировать, потом понять, что вот эта фишка стала deprecated и надо теперь вот так делать - это братцы пересаживаться на другую субд (технологию), что в конечном итоге значит забыть предыдущую…

PS: заранее извинюсь, кое-где грубовато вышло, но как-то по другому не получилось :)

PPS: а еще лучше иметь команду, в которой есть спец по проектированию приложения по бп, спец по проектированию бд, кодер, дизайнер, тестеры, документаторы и самое главное (после сдачи в продуктив) передать его на поддержку саппорту :)

dikoy, сам думал откомментировать вышесказаное… но уже отпала необходимость… респект за пост  ;D полностью поддерживаю

dikoy, согласен.

Quote

сорри, но, imho, это высказывание чушь. если Вы, уважаемый (без тени усмешки) Zolter, действительно в тонкостях разбираетесь и в оракле и в постгресе и в мускуле честь и хвала, а если это высказывание основано на общих принципах оптимизации join'ы тормозят выполнение запроса, искуственные ключи лучше чем естественные, то пердыдущее высказывание чушь.

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

Quote

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

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

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

и не надо мне тут сказки чесать про мега 8 процессорные сервера которые прямо использует каждая вторая фирма в своих проектах. не у всех людях есть возможность отдавать мускулу жрать ресурсы сервера просто так, если есть алтернатива поставить нормальную базу. опять таки повторюсЬ, не у всех как у вас в комнате по 10 мега серверов для каждого проекта выделено.

Quote

опять чушь, легче чего мускул? легче воздуха и взлетает? что значит большая нагрузка - ведро воды что-ли на него ставят? нагрузка на железо на котором работает Ваша СУБД. Как можно оценивать нагрузку на БД. Ну висит у меня сайт с посещаемостью 20 млн чел. в день и 500 запросами на одну страницу на кластере общим числом процессоров 512, все 3Ггц  Xeon'ы восьмиядерные, и терабайтом оперативной памяти ну и что? ни один пользователь не заметит тормозов, даже если я криво спроектирую базу и буду использовать вложенные select'ы повсеместно.

это у вас чушь.

при большом кол-ве одновременных запросов (что я вам и хочу вталковать) postgre вызывает меньшую нагрузку на сервер. конечно если у нас ресурсов неограничено, и сервера можно размножать только ради того что б они использовали мускул - то это для вас не проблема. а там где ресурсы компании ограничены (финансовые имею ввиду), ну представьте себе не все компании могут себе кучу серверов купить, у некоторых только один есть, там они выберают то что будет меньше грузить их сервер и быстрее работать в конечном итоге (http://tweakers.net/reviews/657/6)

ведёте себя как ребёнок которому только надо что и поспорить что б засветиться на форуме. детский сад, честное слово…

Quote

портал на yii пишется? (даже боюсь услышать положительный ответ :) хотя, почему бы и нет, можно ведь и from scratch написать :) размер бд больше терабайта?  :o думается мне однозначно реинжиниринг бд и всего приложения :) как минимум перестать хранить в бд ежедневноый своп от винды :)

ну терабайт и что? ах да, я понимаю, тем кто всю жизнь отработал на мускула таких величин не знать. да портал пишиться на yii, представьте себе не все сторониики писать мега порталы на чистом php что бы получить 10%-ю прибавку в производительности. 

Quote

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

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

Quote

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

что значит подойдет? естественно всё что угодно можно реализовать практически на чем угодно. суть не в том можно написать или нельзя, суть в том рационально это будет или нет. Тоже самое что начать квейк под бейсиком писать только потому что вы будете доказывать что бейсик подойдет для всего чего угодно. это не рационально, а вы как программист должны подавать пример рационального мышления. естественно любой проект можно поднять на мускуле и что? некто не спорит опять таки говорю. любой сайт можно написать на asp, ror, php и тп, и что с того?

Quote

а теперь далее, господа, вот честное слово, просвятите меня горемычного - либо у вас времени валом изучать досконально (в противном случае вообще не смысла изучать) субд которую не знаете, либо проекты у вас такие, что дедлайн через полгода, и то если дождя не будет, читай опять же времени валом. либо вы считаете, что книжка за 500 рублей сделает из вас специалиста?

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

Quote

если вы выучили все что можно, с большой долей вероятности, вы не сможете ничего.

развиваться как известно можно либо вверх, либо вширь… Вы предлагаете развитие вширь…

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

Quote

15 лет программирую, а вот как-то не постиг в деталях кучу языков и технологий. Все как-то сходится к простым вещам - простой проект одна технология, сложный проект другая - и все, нету еще 20 в загашнике. языков знаю (не в плане синтаксиса, а в плане максимального использования возможностей и библиотек) - 3, и из СУБД хорошо знаком только с мускулом и фаербердом - потому как больше не надо было. Хотя и с ораклом сталкивался и с постгресом и с субейзом и с дб2, но не знаю я их - когда-то что-то изучал, но это все забывается еще быстрей чем волосы выпадают - могу чего-нибудь в них сделать, но по моим понятиям это не серьезно - использовать субд с кучей возможностей и не уметь ими пользоваться - лучше уж через известно что на мускуле, а чтобы изучить, протестировать, потом понять, что вот эта фишка стала deprecated и надо теперь вот так делать - это братцы пересаживаться на другую субд (технологию), что в конечном итоге значит забыть предыдущую...

В заключение отвечу уже и на этот абзац.

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

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

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

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

у нас просто не сходиться точка зрения. вы считаете что надо выучить только 1-2 технологии досканально и использовать только их, другие использовать ненадо пока досканально их не узнаете. моя же точка зрения что можно знать досканально то на чем вы работаете ежедневно (php, linux и тп). плюс к этому надо постоянно развиваться и следить за появлением новых технологий, читать их особенности, читать где их лучше использовать и чем они лучше конкурентов. ну вот такая моя позиция, и я думаю она имеет место быть как и ваша. так что моё вам предложение перестать дальше мерятся "письками". я вам совершенно не собераюсь доказывать что мускул отстой, просто не везде стоит его применять. так что предлагаю дальше флуд не продолжать, а вернутся именно к обсуждению темы.