Comments 160
Такой продукт сейчас — заложник себя самого. Переписать с сохранением всех фич такое невозвожно за разумное время. Приходится жить с чем есть.
Я думаю тут не применимо понятие "переписывание" — если начать переписывать с нуля, в любом случае в итоге получится совершенно новая система с другими флагами, свойствами, характеристиками.
Раньше необходимо было поддерживать множество операционных систем (Windows, HPUX, Solaris, и т.д.), различных архитектур процессоров (Intel, Alpha, MIPS, Sparc, и т.д.). Сейчас альтернатив почти нет, можно новый код написать под Intel и Windows/Linux — наверняка это значительно сократит количество различных флагов и систему сборки.
Под spark и pewer чего уж там, а остальным хватит и текущей версии 12.2.0.2 или как сейчас по новой нумерации — 18c :)
Или вы правда думаете, что все эти десятки лет разработчики там каждый день добавляют новую фичу? ))
Посмотрите на любой проект, его движение это очень сложная и запутанная кривая.
Плюс технологии развиваются. Появляются новые языки, тулинг, подходы.
Так что однозначного ответа нет. Нельзя вот так с ходу сказать, что если проект писался 30 лет, то и переписывать с нуля его надо будет тоже 30 лет. В каждом случае свои условия.
И если при переписывании с нуля получится использовать старые тесты (хотя бы частично), то окажется что TDD — это больше плюс, чем минус.
Так что однозначного ответа нет. Нельзя вот так с ходу сказать, что если проект писался 30 лет, то и переписывать с нуля его надо будет тоже 30 лет.
Не тридцать лет, естественно. Переписывать, конечно же, быстрее — не обязательно проживать заново все годы легаси. Но вероятность того, что его переписать будет дешевле, чем сопровождать в текущем виде, настолько ничтожно мала, что ей можно смело пренебречь.
Потому в большем почете написание нового продукта без легаси вообще, чем портирование старых юзкейсов на новые технологии. Даже если за юзкейсы платят. Даже если платят много.
Да, в комментариях к статье на HN писалось именно об этом. Полно старых продуктов, которые написаны ужасно плохо и которые невероятно сложно и дорого поддерживать. Но переписать их никогда не получится, потому что они взаимодействуют с таким же ужасным кодом у пользователей продукта и необходимо соблюдать совместимость с багами и недокументированными особенностями.
Поэтому многие продукты стали заложниками обратной совместимости. В том числе, Windows, Microsoft Office (там же говорилось и о том, что код Office просто ужасен).
Основная проблема и одновременно плюс oracle это то что его использует куча проектов, владельцы которых платят за поддержку, если им указать на дверь в случае если их ПО перестанет работать на правильной новой версии бд, они могут не понять...
В итоге выделяем какие-то части, где можно провести границу (в нашем проекте это, к счастью, возможно) и переписываем часть. Делается это под соусом внедрения новых фич и переноса части кода с C++ на .NET Core.
Fortune 100/500 — это верхушка айсберга. По большому счету, весь крупный энтерпрайс в мире в той или иной степени использует Oracle. Я очень сильно сомневаюсь, что переписать можно будет все без проблем с миграцией.
Обычная миграция между мажорными версиями — это боль. И если вашему предприятию уже лет 10, то в нем не меньший хаос чем в ядре Oracle. Я уверен, что количество фич и триггеров под разные тесты настолько велико, что это просто нереально переписать без значимой потери или изменения функционала.
А теперь, просто представьте во сколько это обойдется Oracle, и мировой экономике эта миграция, вообщем. Представьте, что массово будут происходить аварии вроде этой habr.com/post/429736
Просто, когда читаешь про то, как какой-то стартап все построил и все красивое и новое и без костылей и проблем, я всегда понимаю, что по сути — это на какое-то время и через 5-10 лет этот стартап обрастает таким же количеством легаси кода, которые было при сравнении в их радужных публикациях. Оно так будет, причины могут быть разные: бизнес должен работать пока не начнет из-за этого загибаться (как пример была история Maersk, у которого ИТ не мог выбить деньги на необходимые изменения и вообще как-то повлиять на политику безопасности, пока их не нагнул NotPetya, и компания встала, а клиенты делали миллионные заказы через WhatsApp), да просто внутренняя политика поощрения (как в недавно описанной тут истории про новый интерфейс Gmail), причин может быть тысячи. Проблема в том, что бизнесом правят деньги, и понадобится еще лет 5-10 пока рулевые поймут, что их кораблем в основном управляют алгоритмы, которые требуют значительно большего средств на обслуживание, чем им бы хотелось.
Проблема тут в другом. Крупный рефакторинг или смена продукта заставят клиентов лишний раз задуматься, а не поменять ли СУБД, все равно работы предстоит чуть более чем дофига, если нет желание положить бизнес. И часть клиентов по-любому перейдут, если посчитает такой переход выгоднее или равнозначным по затратам.
Жесть конечно, но можно только похвалить архитекторов, которые внедрили такое использование TDD в свое время.
В описанном в статье воркфлоу ничего не сказано про TDD. Там сказано только про то, что код покрыт тестами и всё. Наличие кода покрытого тестами и использование TDD это совершенно разные вещи.
а может статью прочитать?
Я внимательно прочитал статью и после этого написал комментарий. Такие дела. Я не совсем понимаю, что вы хотели сказать своим комментарием, напишите, пожалуйста прямо. Если вы просто хотели сказать, что я не читал статью — уверяю вас, вы ошиблись.
В команде, которая работала над продуктом в конце 90-ых и придерживалась идей TDD (test-driven development), бытовало следующее мнение: «автоматизированные тесты означают то, что вы не обязаны писать код, который можно будет понять – вместо этого за вас должны думать тесты». В дальнейшем разработчики были вынуждены придерживаться заложенных ими принципами
вернемся к вашему возражению про TDD и совету прочитать статью: то, что не описано воркфлоу, удовлетворяющее TDD, не значит, что TDD там нет. А вот что TDD там есть, хоть и не описано в воркфлоу — на это прямо указано в тексте статьи.
что не описано воркфлоу, удовлетворяющее TDD, не значит, что TDD там нет
Только вот в статье явным образом описано воркфлоу, использование которого исключает практику TDD.
А вот что TDD там есть, хоть и не описано в воркфлоу — на это прямо указано в тексте статьи.
Мой комментарий как раз о том, что нет там никакого TDD. То, что в статье описано как TDD — не является TDD.
Legacy код покрыли юнит тестами.
Если нужно починить что-то — пишете unit test дотверждающий баг, затем чините код, чините поломанные фиксом тесты и пишите новые тесты, покрывающие fix.
Тут только тесты под TDD написать уйдет неимоверное кол-во усилий. И даже это не будет гарантировать 100% покрытия функционала.
А значит, миграция на такую базу вызовет ощутимые потери клиентуры, у которой уже будет выбор мигрировать на Oracle или выбирать среди подросших конкурентов. Для предприятия в обоих случаях все сведется к миграции данных и значительному пересмотру кода.
Но самое отвратительное бывает, когда некоторые группы разработчиков намеренно делают очень непрозрачными отдельные куски с целью ограждения своего кода и скрытия логики кода от других групп разработчиков. Вот тут бывает реальная «веселуха». И совсем печально, когда ответственным за это людям плевать на происходящее или даже все и происходит с их молчаливого согласия.
Не представляю как можно вести разработку проекта командой 100+ у которого тесно связаны части. Видимо там день начинают не с кофе, а с решения конфликтов.
Почему уменьшение связанности кода перестает работать со временем? Потому, что появляются новые требования, которые иногда проходят по частям, которые ранее были не связанными. В результате они становятся связанными. На сотый повтор такой ситуации необходима переработка архитектуры с переписанием кода. Но этого никто не будет делать потому, почти везде ресурсов на горящие проекты уже давно не хватает…
Читай код!Когда код в «молодом» проекте пишется ленивыми, честными и не агрессивными людьми (которые еще и пытаются придерживаться некоторых стандартов), то читать его одно удовольствие. Но когда 90% авторов кода уволились еще лет 5 тому назад, а существущие группы разработчиков через строчку используют предельно редко используемые библиотеки (каждая группа разработчиков при этом использует свой набор библиотек), когда некоторые разрабочтки используют плохо документированные особенности вроде бы стандартных функций (либо используют функции в предельных случаях для достижения побочных эффектов), когда структура модулей не просто не логична, а предельно непонятна — чтение превращается в маленький такой ад. И не всегда оканчивается успехом.
По-моему первая статья с (нехвалебными) результатами (долговременного) TDD,
почему-то такие результаты неуспеха хайповой технологии встречаю впервые
— возможно по причине того что остальные представители коллекции не дожили до стадии анализа?
что-то я пессимистичен сегодня…
По моему, нельзя в этом винить только TDD.
Мне довелось поработать на крупном проекте, где не было тестов вообще, а ситуация с легаси очень похожая. Но так как сам проект на много моложе оракла, и это не база данных, а веб-приложение, то удаление и добавление багов происходило на много быстрее.
Главной проблемой считаю — отказ от рефакторинга. Если делать его своевременно, то он обходится дешевле.
По-моему первая статья с (нехвалебными) результатами (долговременного) TDD
В статье нет ничего про TDD. Вообще ничего. Просто совсем ничего. TDD предполагает, что тесты будут писаться одновременно с кодом, а не когда-то потом.
тесты будут писаться одновременно с кодом
нет — тесты будут писаться до кода
что и видим
есть ошибка (зафиксированный баг) — добавляем ее в пул тестирования — добиваемся что тест проходит
если что-то сломали — чиним, в качестве документации «почему» добавляя новые тесты
этап рефакторинга отсутствует ввиду «некогда… совсем некогда… вы хотите половину системы переписать?! — некогда же!»
нет — тесты будут писаться до кода
С одной стороны вы правильно отметили — тесты для куска кода, который будет писаться в следующие пару минут пишутся до этого куска кода.
С другой стороны за время решения задачи разработчик переключается между кодом и тестами много раз и получается что он написал чуть чуть тестов, потом написал чуть чуть кода. Так что в масшабе задачи тесты и код пишутся одновременно.
что и видим
есть ошибка (зафиксированный баг) — добавляем ее в пул тестирования — добиваемся что тест проходит
В статье написано, что разработчик пишет код, потом прогоняет тесты, потом правит код, если тесты не прошли, а потом пишет дополнительные тесты для своего кода. Он не пишет тест заранее.
этап рефакторинга отсутствует ввиду «некогда… совсем некогда… вы хотите половину системы переписать?! — некогда же!»
В Оракле из статьи похоже так и есть ((
Он не пишет тест заранее.
В описанном процессе исправления бага, мне видится странным писать тест на код исправляющий баг до кода. Что именно на этом этапе тестировать? Кроме того, если с разбором флагов такая морока, то кажется, что нет той головы, в которую поместятся ещё и алгоритмы и параметры тестирования к не родившемуся исправлению. Но когда код исправления пройдёт естественный отбор серией тестирований, он тут же обзаводится собственными тестами. Так что, похоже там всё-таки TDD, но с учётом, что код там уже повзрослел, а разработчики Богами ещё не стали…
В описанном процессе исправления бага, мне видится странным писать тест на код исправляющий баг до кода. Что именно на этом этапе тестировать?
По уму надо написать тест, который предполагает, что код работает нормально. То есть такой тест, который будет воспроизводить баг. Тест проходить, естественно не будет. После этого надо поправить код так, чтобы тест проходил.
Так что, похоже там всё-таки TDD, но с учётом, что код там уже повзрослел, а разработчики Богами ещё не стали…
То что вы описали, с TDD имеет общего только то, что и там и там для кода пишутся тесты.
К сожалению книг, посвящённых именно написанию тестов я не читал. Могу посоветовать всё, что написал Роберт Мартин (тот который Uncle Bob, а не тот, по мотивам творчества которого сняли Игру престолово )) ). Особенно Clean Code, Clean Coder и Clean Architecture. Там везде есть разделы, посвящённые тестированию. Кроме того Мартин ведёт блог https://blog.cleancoder.com/ там много постов про тесты. Ещё есть видео на ютубе где Мартин показывает как заниматься TDD — https://www.youtube.com/watch?v=B93QezwTQpI и https://www.youtube.com/watch?v=qkblc5WRn-U и возможно что-нибудь ещё с ним же.
Ещё есть интересный блог про тестирование https://www.petrikainulainen.net/, там много ссылок на другие блоги.
В общем и целом — научиться TDD сразу не получится. Тут как с ООП и другими методологиями — нужна практика.
Майкл Физерс, "Эффективная работа с унаследованным кодом"
Джерард Месарош, "Шаблоны тестирования xUnit"
Кент Бек, "Экстремальное программирование. Разработка через тестирование"
Роберта Мартина уже упомянули выше
Наоборот, статья показывает преимущества достаточно полного покрытия тестами: даже такой ужасный код остаётся работоспособным.
преимущества достаточно полного покрытия тестами: даже такой ужасный код остаётся работоспособным.
Преимущества? *приподнял бровь*
Вы серьезно?
Сколько еще итераций этого ужасного кода должно пройти, чтобы дальнейшая разработка стала невозможной совершенно?
Чтобы пришлось писать ИскИн, который делает новый код на основе миллионов написанных тестов?
Отсутствие рефакторинга — проблема менеджмента, а не TDD. Абсолютно любая методология в долгом по времени проекте приведёт к созданию говнокода, если периодически не выделяется время на рефакторинг.
Если самолёты какой-то марки всё время падают, но лётчики каждый раз спасаются на парашютах — значит это классные парашюты. Давайте будем на всякий случай комплектовать ими и другие самолёты.
Я просто оставлю это здесь.
Думаю будущее в данной области за ИИ. Людям уже просто не под силу контролировать и проверять такое большое количество строк кода. Ситуации, когда исправление одной ошибки, приводит к появлению новых ошибок, заставляют задуматься.
Мне кажется, изучив такое количество такого кода, ИИ вскочит и убежит. А если не сможет убежать — прикинется дохлым/мёртвым.
А куда ж он денется. "Ни хрена себе у вас запросы — сказала БД и подвисла..."
Интересен с этой точки зрения анализ кода и доказательное программирование, ведь наверняка там под 50% "мертвого" кода.
Но натравить статический анализатор на 25 млн строк — это, ммм, импосибуру, как мне кажется.
Если считать светофор далеким, далеким предком ИИ, то у вас же не возникает беспокойства что светофор отключится от того что на дорогах столько машин, все нарушают, воздух загазован, температура ниже нуля. Как когда-то светофор уничтожил профессию регулировщика так и ИИ уничтожит профессию программиста. Нам не справиться дальше без него. Точнее справиться то мы сможем, но вперед не продвинемся.
Как когда-то светофор уничтожил профессию регулировщика
Не уничтожил. Просто в большинстве случаев регулировщики сидят в мягких креслах и следят да тем, как работает система управления движением.
А если что не так, все так же посылают человека помахать палочкой.
так и ИИ уничтожит профессию программиста.
Не уничтожит. Просто программист будет заниматься по большей части не написанием и поддержанием кода, а надзором за ИИ. А уж когда ИИ оплошает, будет браться за дело сам.
А теперь представьте, насколько сложнее будет этот ИИ в сравнении с системой светофоров.
Вам не стрёмно оказаться в числе тех белковых существ, надобность в которых отпадёт?
ИИ это хорошо, но внедрять и управлять качеством решений будет человек со всей своей жестокостью.
Судебная система на базе ИИ будет как страшный сон и смесь фантазий из черного зеркала и текущих экспериментов китайцев с их рейтинговой системой. Вы будете получать штрафы от ИИ за то что он не смог вас распознать как человека в костюме зайчика, а граничные условия в системе управления автомобилями будут убивать людей, может быть реже чем люди, но это будет значительно страшнее для участников, например потому что какой то разработчик выбрал в качестве допустимой меры выбора кого убивать — количество пострадавших.
p.s. и все самое яркое в этом направлении мы можем увидеть еще при своей жизни!
Автоматизация определения нарушителей на дорогах, в моем городе, дала положительный эффект. Сейчас камеры на перекрестках регистрируют 3 нарушения: красный свет, превышение скорости, непристегнутый ремень. В целом по городу у меня статистики нет на руках, но т.к. являюсь пешеходом, то оценить ситуацию могу. Порядок стал идеальный. Больше нет желающих наехать на стоп линию или не пропустить пешехода.
Ну и ещё такой момент — многие, считающие «пришествие ИИ» благом, думают, что ошибки на начальном этапе персонально их и их родни не коснутся. Как говорится, «а меня-то за что?» Со всеми вытекающими последствиями.
выбора кого убивать — количество пострадавшихВ мире победившего киберпанка такой произвол не может произойти. Там должно быть строго по правилам — кто больше внёс денег компании-производителю ИИ, того спасать в первую очередь.
Siri будет сливать карму Алисе за неудачный комментарий на хабре
Это, конечно (ирония), великолепное применение технологий ИИ в быту :)
К делу:
проблема в том, что если ИИ решит, что вы не нужны (а это рано или поздно случится, когда вы постареете) — вас лишат пенсии. И не говорите мне, что «вы сами себе на старость заработаете». Вас лишат всего, что вы заработаете — потому что вы неэффективны, а значит бесполезны.
Вполне возможно, что вас просто усыпят. А тело переработают на синтетическое мыло.
Это, конечно (ирония), великолепное применение технологий ИИ в быту :)Им надо будет где-то учиться. Форумы отличное место для этого.
что если ИИ решитА если не решит? Откуда у Вас такие мрачные картины в голове. Пока все говорит о том что ИИ будет добрым и справедливым.
Пока все говорит о том что ИИ будет добрым и справедливым.
Им надо будет где-то учиться. Форумы отличное место для этого.
Вы сами себе и ответили :)
После самообучения на форумах ИскИны точно не будут ни добрыми и ни справедливыми.
А если не решит? Откуда у Вас такие мрачные картины в голове. Пока все говорит о том что ИИ будет добрым и справедливым.
Добрым и справедливым значит нерациональным. А машина всегда рациональна.
ИИ придет @ порядок наведет, это, конечно, приятные мысли, но немного наивно надеяться, что он будет добрым и пушистым.
Про пенсии правильно сказали. Зачем рациональному ИИ сливать деньги вникуда, если можно потратить их на ценные ресурсы? Вашу пенсию лучше отдать на туристическую поездку для местных программистов, чтобы у них на 2% выросла продуктивность, а ваши органы — молодому врачу на исследование.
А если не сможет убежать — прикинется дохлым/мёртвым.
Нет, просто это будет рождением SkyNet-а :-D
Но, боюсь, тот код будет еще хуже.
Возникает вопрос: каким же образом при всем этом Oracle Database до сих пор удается держаться на ногах? Секрет — в миллионах тестов.
А что можем мы в России им противопоставить, вернее сопоставить? Разве что планы работы комиссий по импортозамещению!
А зачем им что-то сопоставлять или противопоставлять?
Догоним и перегоним? Как мне кажется, лозунг неверен в принципе.
Хотите написать свою СУБД — пишите. Не хотите — используйте существующую. Или вносите вклад в открытые проекты (тот же Postgres).
А если так ныть, то вы нигде ничего им не сможете "противопоставить" или "сопоставить".
Вы не поняли. Кто и где ноет? И СУБД свою только из-за того что она своя нисать не стоит. Но если она будет поддерживать модель Abrial то и не грех написать. Речь о другом — чем мы можем похвастаться в хорошем смысле этого слова (хотите гордиться).
Догоним и перегоним? Как мне кажется, лозунг неверен в принципе.
Странно. В Советском Союзе так не считали, китайцы так не считают. И если бы мы не догоняли, а потом и не перегнали, то и человечество 12 апреля 1961 года не было бы в космосе. А зачем олимпийские игры проводятся, а зачем американцы на Луну летали!!
Речь о другом — чем мы можем похвастаться в хорошем смысле этого слова (хотите гордиться).
Вы хотите похвастаться результатами работы, к которой вы не имеете никакого отношения кроме одинакового гражданства с авторами?
Ну пока в активе только весьма активное участие в открытых международных проектах вроде Postgres.
Странно. В Советском Союзе так не считали, китайцы так не считают. И если бы мы не догоняли, а потом и не перегнали, то и человечество 12 апреля 1961 года не было бы в космосе. А зачем олимпийские игры проводятся, а зачем американцы на Луну летали!!
Американцы на Луну полетали, забили и забыли. Толку с того.
Надо не догонять или перегонять. Как и всякая формальная метрика человеческой деятельности это чаще приводит к глупостям и злоупотреблениям, чем к полезному результату (правда помнят обычно только эпические победы и столь же эпические провалы). Если посмотреть историю Китая, СССР да и тех же США, там полно всякого бреда, связанного с "догнать и перегнать" (причем не только международного).
Надо просто делать свое дело, не делая целью именно "догнать и перегнать", а стараясь сделать результат своей работы настолько хорошим, насколько это возможно.
Но, к сожалению, современное общество заточено только на гонку. И вся мотивация у людей только в этой гонке, на которую бездарно гробятся ресурсы. Результат, конечно, есть. Как же без результата. Только путь его достижения оптимальностью даже не пахнет.
Зачем проводятся олимпиады? Цель давно уже осталась только одна — заработать много бабла. Спортсмены там только для антуража.
Вы хотите похвастаться результатами работы, к которой вы не имеете никакого отношения кроме одинакового гражданства с авторами?
Это вы о ком? Если о себе, то вам виднее. Если вы о ком-то другом, то назовите, если уверены в своих словах.
Цель давно уже осталась только одна — заработать много бабла.
Хорошо вы мнения о человечестве. Хотя сегодня вы правы.
Многие тут спорят TDD в Оракле или не TDD )) Народ, могу успокоить в версии Oracle многие вещи имеют «иное» понимание — от их реализации STL (особенно под UltraSparc лол) до их понимания паттернов проектирования в те года (особенно запомнилась с тех времен реализация PImpl).
Мое мнение Oracle существует только потому, что Ларри подмазал везде и у ЦРУ и IBM, и Apple, и Sun (когда он еще существовал) он с кем надо давно договорился — просто посмотрите его биографию и станет понятно — почему этот монстр до сих продается (только не надо мне про масштабируемость решений от Оракл) И да, легко верю автору, что хуже кода базы Оракл нет ничего в мире))
Т.е. когда готовые решения из opensource вас чем то не устроят, вы платите своей команде, чтобы они улучшили ее. В итоге у вас будет на руках команда (которая стала лучше потому что получила опыт и деньги за него) а сообщество получит улучшенное решение. Пока этот процесс не прекращается, вы будете объективно в плюсе.
Недостатки метода — вы можете растерять команду из-за внутренних организационных проблем или длительного отсутствия денег. Но если сравнивать с готовыми железными решениями — машина отработает свой срок и все, деньги на нее гарантированно уйдут в песок.
Так же есть риск напороться на проблему, сложность решения которой сравнительно выше абстрактного готового решения по железу.
Если я правильно понимаю суть TDD и юнит тестирования в целом- то код должен был тестироваться атомарно и без зависимостей, что в общем то исключает возможность спагетти.
Ежели под «ТDD» тут понимается написание функциональных тестов перед написанием кода, то значит есть хорошая документация. Это должна быть хорошая отправная точка для декостылизации.
Ежели под «TDD» здесь понимается написание больших интеграционных и функциональных тестов после кодинга, то получается… что написание интеграционных и функциональных тестов (и только) это яд для больших проектов. Никогда не думал о таком.
Ежели суть TDD я понимаю не правильно. То я точно узнаю об этом от комментаторов -)
Цикл классического TDD состоит из 3 шагов:
- красный (новый тест на функциональность, которой ещё нет)
- зелёный (реализовали функциональность любым способом, даже самым костыльным)
- рефакторинг (имея зелёные тесты, немного причесали код)
Если рефакторинг не проводится, то не стоит называть имеющийся процесс словом TDD. Это что-то другое.
Предположим, что вы супер крутой разработчик с зарплатой 5000 долларов чистыми.
И вот с этим Вашим гигантским опытом разработки, Вы правда думаете, что знаете лучше чем Ларри Эллисон/топ менеджеры Oracle/управленцы любой многомиллиардной корпорации? Правда лучше знаете?
Вот когда у Вас будет своя корпорация стоимостью несколько миллиардов долларов, построенная с нуля, вот тогда к Вам может и будут прислушиваться, а может и нет.
слившиеся Alcatel и Lucent и затем поглощённые Nokia и т.д.
У Оракл ещё всё впереди. Из современных айтишных компаний с реально долгой историей разве что IBM вспоминается.
Я не утверждаю, что Oracle живее всех живых и самая технологичная компания в мире. Я лишь говорю, что Oracle'у до смерти как пешком до луны. Всё таки развалить многомиллиардную корпорацию не так просто.
Как тогда объяснить, что на протяжении 10 лет, как я работаю с этой БД
1) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?
2) Oracle одна из наиболее стабильных БД?
Ну допустим еще можно объяснить стабильность тестами.
Но будь кодовая база ужасна вы никогда не сможете ее развивать быстрее конкурентов. Ну или в конкурентов еще хуже :)
Да понятно, что код не конфетка. Ведь Oracle поддерживает одновременно много платформ и ОС. И все это высоконагруженный код. Где скорость должна бить бескомпромиссная. Понятно, что без грязных хаков никак не обойтись.
Но и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестовэто мягко говоря преувеличение. Наверное, есть <1% кода, который может вызвать такое поведение. Но не все 25 миллионов.
Мне нравятся люди, которые здесь с лёгкостью критикуют. Но кто из вас архитектор, или хотя б тимлид команды, которая работает с кодовой базой 25 миллионов строк?
Или работает с кодом, который приносить многомиллиардную прибыль?
Скажу просто, у нас не тот уровень чтоб критиковать работающий проект такого уровня. И все что ми знаем это со слов людей которые по разным причинам уже не работают в этой компании
1) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?
Можете привести примеры?
Мощность PL/SQL. (Никто и близко не наблизился за много лет )
Возможности администрирования, которим равних нет нигде.
Чтоб не гуглить что такое RESULT_CACHE ,Inmemory
habr.com/post/422669/#comment_19094311
Относительно скорости в стате яндекса сказано что после миграции на postgree серверов стало больше.
Если не согласны — Приведите обратний пример. Кто развивает БД быстее? Я не вижу никого на ринке. даже IBM забросил идею создать для DB2 PL/SQL 100% совместимый.
Относительно скорости в стате яндекса сказано что после меграции на postgree серверов стало больше.
Ещё бы! На те деньги, в которые обходится лицензия Oracle на один сервер можно развернуть парк серверов на Postgresql и для надёжности его продублировать )))
Например, меня очень сильно интересует, а можно в 2 клика мышкой (окей, в 2 команды в sqlplus) сделать shrink database? Или как сделать бэкап, который не таскает туда-сюда tablespace с пустыми местами? А то меня тут просят иногда помогать нашему Oracle DBA, а я после MSSQL чувствую себя неуютно.
Для беккапов есть RMAN. И ничего лишнего.
Для уменьшения датафайлов.
mmokaev.blogspot.com/2015/11/plsql-oracle-shrink-tablespace.html
Просто в oracle можно делать в онлайне то что в других без остановки никак.
Например восстановление битого блока в онлайн или перенос данных на другой диск в онлайн.
Работа с оптимизацией запросов и тд.
Oracle, может, и развивается быстрее всех, но вот тут: DB-Engines, например, нарисована несколько менее оптимистичная картинка.
MySQL по популярности такая же как Oracle. Так что фичи тут вообще не при чём.
Разная ЦА, если перефразировать кратко.
Не вижу причин, почему этого я бы не сделал.
TLDR: проблема не в технической области, а в организационной.
Зачастую есть следующая логика:
- В жирной компании используют Oracle как базу данных в 80% случаях
- Вас как тимлида (т.е. вы кодите в лучшем случае как 1/10 от стандартного разработчика) спрашивают — разработайте архитектуру на бумажке и покажите нам.
- Вы выписываете кучу вещей, микросервисы и т.д. И начинаете выбирать базу, однако:
3.1. Если вы выберете что-то нестандартное, то все ошибки будут лично вашими проблемами (ну т.к. ваша инициатива — вы и виноваты)
3.2. Достижения могут не монетизироваться, т.е. вряд ли база данных вам прям радикально поможет что-то сделать лучше.
3.3. Ряд людей из менеджмента (такие бывшие разработчики, которые вам четко объяснят, какими они были четкими программистами, правда вы нигде не найдете их крутых приложений, да и код свой они не покажут) будут предлагать не выпендриваться, а использовать "проверенные решения" - И дальше, если вы таки решите внедрить базу, то:
4.1. Вы таки внедрите MariaDB. И любая ошибка ударит по вам. Вы не отмажитесь фразой "дык все используют, я полагался на опыт коллег"
4.2. В других командах тимлиды не забудут высказаться, что есть тут один смузихлеб, который не любит Oracle. Ну ибо зачем выпендриваться? - Если вам повезет, то в вашей компании будут использовать Oracle в 79,9% случаев (а было 80%)
- Если вам не повезет (ну просто проект не пошел в гору), то тимлид из другой команды, при выборе базы, будет получать контраргументы в стиле "ну там какой-то khanid внедрял MariaDB, но проект не взлетел".
По сути успех Oracle во многом связан с тем, что они были первыми когда-то, а потом научились договариваться с бизнесом.
У них области применения практически не пересекаются.
Оракл версионник и расчитан на олтп нагрузку с большой конкурентностю за ресурсы и “длинными транзакциями”
Mysql блокировщик. И с этим там совсем плохо.
Я не говорю что невозможно решать ети проблемы в Mysql, но крови попет, и рано или поздно вам придется усложнять и усложнять логику для разруливания проблем с блокировками. Я лично использовал Mysql c достаточно большими таблицами и огромным объёмом загружаемой информации, но нагрузка DW.
У всех больших организациях используются 3-7 разных баз данных. И поэтому выбор осуществляется не по принципу возьмём самую дорогую, а какая больше подходит для задачи.
Представьте что Oracle Enterprise edotion стал бесплатен, совсем, что произойдёт?
Ну пусть не ee а standard без ограничений, как думаете?
Основная притензия в том, что архитектура совсем не модульная и всё держится на тысячах bool flag. Возможно, это был единственный способ писать код в 70х. А Oracle пишут с начала 70х. Что проект ппц какой монолитный.
Работаю с кодовой базой в 15 000 000 строк. Есть код, который не трогается уже лет 20. А есть бизнес логика и уровни пользователей, которые переписываются постоянно. Всё покрыто тестами.
1) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?
Смешно. Может я, конечно, и адепт MS SQL Server, а потому не могу судить объективно (как и вы), но имел опыт работы и с Oracle. Вот что сразу в голову пришло:
1) Напрягало отсутствие возможности определить кластеризованный индекс (IOT в оракле) не по первичному ключу. Напрягало, что по умолчанию IOT содержит только сам PK, а не располагает все колонки всех записей в заданном порядке.
2) Напрягало отсутствие возможности определить включенные (INCLUDE) колонки для не IOT-индексов, зачем-то оракл их не может не индексировать, но я-то знаю, что мне это не надо.
3) Не очень удобные планы запроса (субъективно и в сравнении). Нет онлайн-планов запроса, как в MS SQL. Зачем-то внезапно нужно для планов запросов еще и табличку создавать отдельную в БД.
4) COLUMNSTORE INDEX не завезли в Oracle.
Еще сильно бесило, что ораклисты пишут курсоры направо и налево, в частности для соединения двух таблиц(!), имитируя LOOP JOIN, пишут на устаревшем стандарте (FROM table1, table2 WHERE (+)...), но это просто мне такие только попадались.
Если расскажете про плюшки оракла — будет интересно почитать, ибо я уже давненько не углублялся сильно в СУБД, перейдя со скуля на C#. Но говорить что оракл впереди планеты всей — как-то слишком.
у оракла не плюшки, он лет 20 как на другом уровне относительно остальных субд. только цена весь праздник портит. у оракла есть полноценный кластер, который в самом деле масштабируется и дает реданденси. собственно потому оракл практически всех из фин сектора вытеснил - никто другой из реляционок не позволит просто добавлять узлы в кластер и обслуживать большие нагрузки.
ну и по мелочи, у оракла явно язык сторед процедур на ином уровне ем у остальных, с его пакетами и разделением дефиниции пакета и тела, отслеживание зависимостей. довольно интересная концепция с exadata, где сторидж стал совсем умным и отделен от компьют узлов. там фуллскан с предикатами уже не вычитывают все блоки таблицы как у других субд.
по IOT вы что-то не разобрались - оракл по умолчанию хранит именно всю строку в узле индекса.
Безумие и успех кода Oracle Database