Сам был как водителем, так и пассажиром Bla-bla(Украина).Высокий рейтинг и тд. И мне нравилась их философия. Я агитировал пользоваться их сервисом своих друзей. У меня были регулярные поездки 430 км. и это било очень удобно. Старался выбирать попутчиков или водителей по отзывам.
Но где-то год назад я увидел, что по некоторым направлениям >80% поездок коммерция. С практически отсутствующими отзывами и 2-4 объявлениями на одну поездку. С того времени я перестал пользоваться их сервисом.
Я надеюсь, что их способ монетизации потерпит крах. Где логика: Большинство водителей коммерция, а брать деньги с пассажиров.
Никого не хочу обидеть, но все-таки рассматривать в одном проекте выбор между oracle и mysql?
У них области применения практически не пересекаются.
Оракл версионник и расчитан на олтп нагрузку с большой конкурентностю за ресурсы и “длинными транзакциями”
Mysql блокировщик. И с этим там совсем плохо.
Я не говорю что невозможно решать ети проблемы в Mysql, но крови попет, и рано или поздно вам придется усложнять и усложнять логику для разруливания проблем с блокировками. Я лично использовал Mysql c достаточно большими таблицами и огромным объёмом загружаемой информации, но нагрузка DW.
У всех больших организациях используются 3-7 разных баз данных. И поэтому выбор осуществляется не по принципу возьмём самую дорогую, а какая больше подходит для задачи.
Вы ставите неправильные вопросы
Для беккапов есть RMAN. И ничего лишнего.
Для уменьшения датафайлов. mmokaev.blogspot.com/2015/11/plsql-oracle-shrink-tablespace.html
Просто в oracle можно делать в онлайне то что в других без остановки никак.
Например восстановление битого блока в онлайн или перенос данных на другой диск в онлайн.
Работа с оптимизацией запросов и тд.
Навскидку из относительно нового, RESULT_CACHE ,Inmemory, multitenant, Разнообразие партиций.
Мощность PL/SQL. (Никто и близко не наблизился за много лет )
Возможности администрирования, которим равних нет нигде.
Чтоб не гуглить что такое RESULT_CACHE ,Inmemory habr.com/post/422669/#comment_19094311
Относительно скорости в стате яндекса сказано что после миграции на postgree серверов стало больше.
Если не согласны — Приведите обратний пример. Кто развивает БД быстее? Я не вижу никого на ринке. даже IBM забросил идею создать для DB2 PL/SQL 100% совместимый.
Давайте на минуточку представим, что код БД настолько ужасен как написано.
Как тогда объяснить, что на протяжении 10 лет, как я работаю с этой БД
1) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?
2) Oracle одна из наиболее стабильных БД?
Ну допустим еще можно объяснить стабильность тестами.
Но будь кодовая база ужасна вы никогда не сможете ее развивать быстрее конкурентов. Ну или в конкурентов еще хуже :)
Да понятно, что код не конфетка. Ведь Oracle поддерживает одновременно много платформ и ОС. И все это высоконагруженный код. Где скорость должна бить бескомпромиссная. Понятно, что без грязных хаков никак не обойтись.
Но и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов
это мягко говоря преувеличение. Наверное, есть <1% кода, который может вызвать такое поведение. Но не все 25 миллионов.
Мне нравятся люди, которые здесь с лёгкостью критикуют. Но кто из вас архитектор, или хотя б тимлид команды, которая работает с кодовой базой 25 миллионов строк?
Или работает с кодом, который приносить многомиллиардную прибыль?
Скажу просто, у нас не тот уровень чтоб критиковать работающий проект такого уровня. И все что ми знаем это со слов людей которые по разным причинам уже не работают в этой компании
как узнать, сколько ему памяти выделено (сколько значений кэширует БД? это вообще как-то конфигурируется?)
Конфигурируется на уровне БД (Задается сколько памяти виделить на кеш.). Там же есть статистика сколько попаданий, сколько раз пересчитало, и сколько витеснено с кеша хороших значений. При большом количестве последнего желательно увеличивать кеш(или уменшать количество кешируемих результатов)
Можно смотреть сдесь docs.oracle.com/database/121/TGDBA/tune_result_cache.htm#TGDBA616
RELIES_ON нужен только в 11R1. В следующих версиях он уже считается устаревшим.
И согласитесь решение на PL/SQL Простое и елегантное. Практически не требует дополнительного кода.
Именно так, статую мне вычитали. Да и в моих комментариях встречаются ошибки, иногда я и комментарии прогонял через проверку, Но тема уж больно интересная. Хотелось по скорей прокомментировать. Если уж обидел «верующих» извините. Я не со зла.
Главное любите людей и используйте вещи, а не наоборот.
Беда в том что мы не умеем отдыхать. И это не беда инженеров, или других профессий, это общее наследие.
Мы не умеем наслаждаться общением с любимыми, или просто посидеть у камина, или на лавочке, или на опушке леса.
Нет я и сам без активности и несколько дней не могу провести. Но ведь можно и в огородике копаться, в лес сходить. Пройтись за ручку.
И да, я планирую уйти на пенсию в 50, ну в смысле резко сократить свои рабочие часы.
Хотя я и сейчас не брезгую отдохнуть побольше. :) Ибо жизнь это здесь и сейчас.
А вся эта мишура — телефон последней модели, машина побольше кроме понтов ничего не даёт.
Давайте быть чесними — надежд на пенсию нет. И не важно сколько ти зарабатывал и отчислял в фонд — высокие пенсии будут в конце концов только у чиновников и силовиков.
Поетому нужно разчитивать на пенсию с собственних накоплений. На государственную пенсию разчитивать нельзя. И чем больше и раньше люди ето поймут тем лутше для всех.
Цена
1 ядро с всеми необходимыми опциями по прайсу около 100 000$ По факту цена на половину+ рассрочка.
Ежегодно еще 10 000$. Но стоит учесть, что это не обязательно, ибо эта плата за поддержку и обновления и на легальность продукта не влияет.
Рассматривать покупку чего то кроме Enterprise на мой взгляд смысла нет.
Если вам не нужен Enterprise, точно можно обойтись чем-то дешевле или бесплатным.
Для примера 2х ядер Power 7+ достаточно чтоб работала OLTP система для 100 продуктовых супермаркетов.
Ну вот и считаем. 3 лицензии (2+1 стенбай) 150 000$ + ежегодно 30 000$ Дорого это или нет?
Партишин.
Да уже почти год он есть в посгри.
Но кроме того что он есть, не поленитесь почитать о существующих проблемах.
И после этого решите готовы ли вы использовать их в продакшене.
Я несколько раз начиная новый проект изучал возможность использовать посгри.
Ибо люблю свободный софт, и стараюсь использовать его, когда это целесообразно.
Merge
В комментариях несколько раз проскакивало INSERT… ON CONFLICT
так я отвечу, чем не устраивает — ON CONSTRAINT constraint_name
И скажите на каком месте merge в списке ожидаемых фич посгри? Разве
Специалисты посгри не знают о INSERT… ON CONFLICT?
Да и будь merge синтаксический сахар над INSERT… его б давно реализовали.
Ну и да, merge чаще используется для DW.
Все что я написал — реально помогало на реальном проекте(перешли с 8 ядер на 2 с общим улучшением быстродействия).
давайте по порядку. Партиции.
В табличке более 500 000 000 записей это информация за 5 лет.
И это не просто табличка в которую делаются insert.
в таблице несколько индексов. Когда идет движение по этой таблице — идет изменение остатков.
Тем не менее благодаря патрициям и субпартициям нет никаких опасений, что через 5 лет придется что-то менять.
Merge существенно ускорил задачи DW. Больше нечего написать.
RESULT_CACHE (Select) (Если грубо — кеширование результата запроса в памяти (для тех кому лень погуглить), с автоматическим пересчетом результата в случае изменения таблиц.)
Поверте ето совсем не то что материализованные вюхи, которые кстати в оракле есть с незапамятних времен) RESULT_CACHE (Function) Если грубо — кеширование результата запроса функции в памяти (для тех кому лень погуглить), с автоматическим пересчетом результата в случае изменения таблиц, от которых зависит результат функции)
Это настолько крутая фича, что ми ее начали использовать, как только вышел oracle 11R1.(Ми даже пренебрегли золотим правилом использовать новые фичи через релиз.
B конце концов ми нарвались на баг который исправили только 11R2 для нашей платформы)
Самый простой кейс использования в проверке прав пользователя у вюхах(у нас сотни видов объектов в каждом объектов от 10 — до 10 000).
Права как индивидуальнее так и на профили, причем индивидуальнее как на расширении прав так и на сужение.
Чтоб получить результат функции — нужен запрос к нескольким таблицам. (Да, до этого ми использовали кеширование, без него вообще никак)
Благодаря только простой кляузе RESULT_CACHE ми получили более плавный интерфейс, который ощутили все сразу.
Пожалуйста назовите мне аналогичную вещь (для решения данной задачи) в посгри.
Inmemory.(если уж совсем по простому(для тех кому лень погуглить) — табличка размещается в памяти.) Ну да, ето совсем свежая фича. всего то 5 лет ей. :) Я даже не представляю, как объяснить выгоду от нее. Кстати в списке ожидаемых фич посгресовци ее ждут, не так как merge, но все же ждут.
PL/SQL Можно спорить о размещении бизнес логики в БД. Сейчас ето не модно.
Но все же PL/SQL очень бистр. Некоторые вещи я перечислил. Это вообще не полный список, и может даже очень плохой.
P.S. Я написал, что я не эксперт оракл. Ибо чтоб пересчитать реальных экспертов в оракл, наверное, хватит пальцев одной руки.
Как только начинаешь углубляется в детали, понимаешь, что ты не знаешь и 30% возможностей этой БД. Я даже не уверен, что возможно знать хотя б 80% всех возможностей БД.
Я всегда с интересом слежу за выходом новых версий разных БД. Особенно слежу за статьями о посгри. Я всё-таки надеюсь что она выйдет на уровень когда можно будет ее рассматривать как альтернативу ораклу.
И да я писал под разные БД. включая sqlite, mysql, mssql, oracle, И где ето возможно и рационально использовал встроенные языки.
(за плечами многие десятки тысяч строк кода, который работает в продакшене и годами не требует вмешательства) и все равно я не эксперт ни одной БД. А если мне нужно начать работать с новой для меня БД я сначала изучаю нюансы работы этой БД, а только после этого начинаю строить архитектуру БД и писать код.
И да, чуть ли не первое что читаю — это нюанс с null :)
Тем более 2 последних года я больше пишу кода для MsSQL.
И да я уверен, что любую задачу можно решить на любой вменяемой БД.
Вопрос лишь в архитектуре и необходимом усложнении алгоритмов.
Я не религиозный фанатик оракл, я использую БД в зависимости от проекта, наследия, правил и ТД.
Скажу больше било время, когда я любил MySql за простоту и скорость.
P.S.S. Главное что я хотел донести что прокомментировал onix74 ( и собрал наибольше лайков) https://habr.com/post/422669/#comment_19087833
Я процитирую "
И ещё, по-моему, неверно сравнивать enterprise с Posgtres. Сравните, например, бесплатный Oracle XE, или, на худой конец, Oracle Standard Edition 1 (11G) / Standard Edition 2 (12c).
"
Переведу как я это понимаю — oracle enterprise и Posgtres ето продукти для разных сегментов. И низя считать, что Posgtres c лёгкостью заменит oracle enterprise. Если вы с этим согласны — не зря я писал эту статью и угробил карму :)
P.S.S.S. Я в отпуске(слишком поздно промодерировали), и не могу в онлайн комментировать. Некоторые коменти я постараюсь ответить завтра.
А от себя еще добавлю
1) RESULT_CACHE
2) Разнообразие Partition, отсутствие SubPartition.(в MsSQL на уровне 8i, в PostgreSQL в десятке прикрутили но до использования в продакшене им пилять и пилять)
3) INMEMORY(опция) — в MsSQL мягко говоря странное, в PostgreSQL нет., Да что говорить в PostgreSQL merge до сих пор нет и не будет в 11.
4) PL/SQL заточен на скорость, масовие обработки, компиляция в нативний код и тд.
Все ето дает прирост быстродействия в на некоторих участках в десятки раз.
Ви можете себе представить перенос дата файла с диска на диск или востановленя «битого блока» в состоянии Online?
А Переход на новие сервера без остановки работи БД?
От таки «маркетинговие» фичи позволяют БД бить в Online годами.
Если расматривать базу для OLTP то Oracle БД №1.
1) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.
2) Простое маштабирование из коробки.
3) Удобство администрирования, отказовоустойчивость и возможность поддерживать систему Online 7*24. И очень многие вещи можно делать без остановки базы.
И да Oracle очень догогой, но если сравнивать не просто стоимость лицензий, а реальную нагрузку, которую держит система то разныци с MsSQL практически не будет.
Для DW можно использовать и MySQL и PostgreSQL.
Я могу сравнивать ибо пишу под MsSQL и Oracle, писал и MySQL и баловался PostgreSQL.
Какая информация на хабре проскакивала несколько раз в холиваре БЛ БД или вне БД.
Мы все ето вместе можем легко проверить. Вы предлагаете сценарий БЛ и реализацию JAVA\С#. Я код PL\sql. Желательно что то посложнее, ибо 90% логики можно реализовать оператором (select\merge\update\insert) или их групой. Но сразу оговорим, что задача должна включать многопользовательский режим, и возможность совмесной работы и контроль прав ограничения на даные.
Речь шла про удобство и ограниченность дебага. Ну, вот оно, ограничение — прямо на дебаге понять почему тормозит запрос невозможно.
Никогда в таком русле не думал. Всегда смотрел план отдельно в Тоде там ето получше сделано. Согласен прям в дебагере — удобнее.
Я согласен — дебаг и GUI похуже Студии еклипса и тд.
*глядит в портянки pl/sql, потом в свой уютненький java-код* Ээээ… Ладно, проехали :D
В девелопере достаточно удобная навигация по коду. Ну а портянки ето уже стиль :) а не маст хев. Но ето уже кому что глазу мелее. Мне например не нравится в JAVA\C# многословие в описаниях класа (public, і тд.). Спасибо хотя б в JAVA var добавили :) Наследование, интерфейси итд часто отвлекают от сути, и получается что обертка становится важнее сути. Не подумайте что я не люблю ООП. Я очень любил с++, Сейчас пишу на c#. Но заглянув в grid(C#), я больше не задавался вопросом почему он такой тормознутый. Мне кажется что ето уже слишком. Я понимаю что там все красиво, канонически. Но работать бысто ето не может… Да Я не знаю как сделать так же уневерсально и быстро. Наверно ето и невозможно. Поетому и появлялись пачками самописние grid. Но ето уже другая история.
У меня даже теоретической идеи нет как можно дебажить декларативний язык.
План запроса ето и есть, как по мне, его дебаг. И чуть ли не базис скорости работы.
реализация бизнес логики на БД наиболее правильное место
несколько сомнительно.
Я даже скажу больше очень немодно. :) и ета мысль часто жостко минусуется на хабре. Но тем неменее, в целом код написаний на ХП короче аналогичного JAVA\C# значить проще тестится. Проще поддерживается, В случае простых изменений не требует переинстеляции на клиенских машинах. Значит изменения можно внедрять быстрее.
И как я уже писал ниже я не агетирую за БЛ на ХП я агитирую Что выбор Базы и знание нюансов не менне важен за выбор язика програмирования. А по большому счету даже важнее.
Если б был идеально правильний вариант «серебряная пуля» все так бы и работали, ну или почти все :). У каждого подхода есть свои плюсы и минусы. Ведь не секрет что на сегоднишний день в БД является узким местом во многих задачах. И оно узко именно через то, что БД используют неправильно, или вибор БД бил ошибочен. Проще всего через неделю, месяц или год когда система становится «ватной» или начнет «залипать» сказать: «Ми же все зделали идеально: используем наимоднейшие технологии и последние фичи языка, абстракции, SOLID, покрыли все тестами, і тд. Ето все криворукее админы БД ведь БД ето только быстрое хранилище, а почему оно не достаточно быстрое ето их забота, пусть разбираются и добавят какието там индексы». А админы разведут руками и скажут — ведь там блокировки, борьба за ресурсы, тисячи запросов вместо одного. И дай бог им общими усилиями найти выход или полувыход из ситуации.
Я участвовал в разработках где вся БЛ на БД, и где на БД запрещены ХП (Слава богу хотя foreign key разрешили). Я скажу так, не важно какой путь вы вибрали. Всегда нужно помнить: Каждая БД имеет свой «характер» И то что на MSSQL\Oracle\MySQL\Postgresql\… работает на ура в другой БД может тупить, или вообще не работать. Если у вас OLTP система — не знание етих нюансов ето смерть в продакшине. Я не агетирую за БЛ на БД. Я агитирую за то что разработчик должен знать особенности БД которую будет использовать. И ето значительно важнее для качественного продукта чем знатие всех фич язика или нових фреймворков.
P.S. И да для меня для меня скорость и отзывчевость програмы ето один из главнейших критетеев програмы на равне с юзебилити.
И я видел людей, для которых отритие документа в 1 минуту уже не проблема, они смирились и считают ето нормой. Видя такой софт грусно становится…
Да целую колекцию не посмотриш. Только елемент. Даже FIRST елемент не покажет.
Етому есть наверное логичное обеснение.
Согласен. отладка в VS намного удобнее и мощнее.
С етим пунктом я ввел в заблуждение. Можно сказать что отладка присутствует но ограничена.
Но где-то год назад я увидел, что по некоторым направлениям >80% поездок коммерция. С практически отсутствующими отзывами и 2-4 объявлениями на одну поездку. С того времени я перестал пользоваться их сервисом.
Я надеюсь, что их способ монетизации потерпит крах. Где логика: Большинство водителей коммерция, а брать деньги с пассажиров.
У них области применения практически не пересекаются.
Оракл версионник и расчитан на олтп нагрузку с большой конкурентностю за ресурсы и “длинными транзакциями”
Mysql блокировщик. И с этим там совсем плохо.
Я не говорю что невозможно решать ети проблемы в Mysql, но крови попет, и рано или поздно вам придется усложнять и усложнять логику для разруливания проблем с блокировками. Я лично использовал Mysql c достаточно большими таблицами и огромным объёмом загружаемой информации, но нагрузка DW.
У всех больших организациях используются 3-7 разных баз данных. И поэтому выбор осуществляется не по принципу возьмём самую дорогую, а какая больше подходит для задачи.
Для беккапов есть RMAN. И ничего лишнего.
Для уменьшения датафайлов.
mmokaev.blogspot.com/2015/11/plsql-oracle-shrink-tablespace.html
Просто в oracle можно делать в онлайне то что в других без остановки никак.
Например восстановление битого блока в онлайн или перенос данных на другой диск в онлайн.
Работа с оптимизацией запросов и тд.
Мощность PL/SQL. (Никто и близко не наблизился за много лет )
Возможности администрирования, которим равних нет нигде.
Чтоб не гуглить что такое RESULT_CACHE ,Inmemory
habr.com/post/422669/#comment_19094311
Относительно скорости в стате яндекса сказано что после миграции на postgree серверов стало больше.
Если не согласны — Приведите обратний пример. Кто развивает БД быстее? Я не вижу никого на ринке. даже IBM забросил идею создать для DB2 PL/SQL 100% совместимый.
Как тогда объяснить, что на протяжении 10 лет, как я работаю с этой БД
1) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?
2) Oracle одна из наиболее стабильных БД?
Ну допустим еще можно объяснить стабильность тестами.
Но будь кодовая база ужасна вы никогда не сможете ее развивать быстрее конкурентов. Ну или в конкурентов еще хуже :)
Да понятно, что код не конфетка. Ведь Oracle поддерживает одновременно много платформ и ОС. И все это высоконагруженный код. Где скорость должна бить бескомпромиссная. Понятно, что без грязных хаков никак не обойтись.
это мягко говоря преувеличение. Наверное, есть <1% кода, который может вызвать такое поведение. Но не все 25 миллионов.
Мне нравятся люди, которые здесь с лёгкостью критикуют. Но кто из вас архитектор, или хотя б тимлид команды, которая работает с кодовой базой 25 миллионов строк?
Или работает с кодом, который приносить многомиллиардную прибыль?
Скажу просто, у нас не тот уровень чтоб критиковать работающий проект такого уровня. И все что ми знаем это со слов людей которые по разным причинам уже не работают в этой компании
Конфигурируется на уровне БД (Задается сколько памяти виделить на кеш.). Там же есть статистика сколько попаданий, сколько раз пересчитало, и сколько витеснено с кеша хороших значений. При большом количестве последнего желательно увеличивать кеш(или уменшать количество кешируемих результатов)
Можно смотреть сдесь
docs.oracle.com/database/121/TGDBA/tune_result_cache.htm#TGDBA616
И согласитесь решение на PL/SQL Простое и елегантное. Практически не требует дополнительного кода.
Главное любите людей и используйте вещи, а не наоборот.
Мы не умеем наслаждаться общением с любимыми, или просто посидеть у камина, или на лавочке, или на опушке леса.
Нет я и сам без активности и несколько дней не могу провести. Но ведь можно и в огородике копаться, в лес сходить. Пройтись за ручку.
И да, я планирую уйти на пенсию в 50, ну в смысле резко сократить свои рабочие часы.
Хотя я и сейчас не брезгую отдохнуть побольше. :) Ибо жизнь это здесь и сейчас.
А вся эта мишура — телефон последней модели, машина побольше кроме понтов ничего не даёт.
У меня вопрос вы реально верите в пенсию, или минус только за грамматику?
Поетому нужно разчитивать на пенсию с собственних накоплений. На государственную пенсию разчитивать нельзя. И чем больше и раньше люди ето поймут тем лутше для всех.
1 ядро с всеми необходимыми опциями по прайсу около 100 000$ По факту цена на половину+ рассрочка.
Ежегодно еще 10 000$. Но стоит учесть, что это не обязательно, ибо эта плата за поддержку и обновления и на легальность продукта не влияет.
Рассматривать покупку чего то кроме Enterprise на мой взгляд смысла нет.
Если вам не нужен Enterprise, точно можно обойтись чем-то дешевле или бесплатным.
Для примера 2х ядер Power 7+ достаточно чтоб работала OLTP система для 100 продуктовых супермаркетов.
Ну вот и считаем. 3 лицензии (2+1 стенбай) 150 000$ + ежегодно 30 000$ Дорого это или нет?
Партишин.
Да уже почти год он есть в посгри.
Но кроме того что он есть, не поленитесь почитать о существующих проблемах.
И после этого решите готовы ли вы использовать их в продакшене.
Я несколько раз начиная новый проект изучал возможность использовать посгри.
Ибо люблю свободный софт, и стараюсь использовать его, когда это целесообразно.
Merge
В комментариях несколько раз проскакивало INSERT… ON CONFLICT
так я отвечу, чем не устраивает — ON CONSTRAINT constraint_name
И скажите на каком месте merge в списке ожидаемых фич посгри? Разве
Специалисты посгри не знают о INSERT… ON CONFLICT?
Да и будь merge синтаксический сахар над INSERT… его б давно реализовали.
Ну и да, merge чаще используется для DW.
Все что я написал — реально помогало на реальном проекте(перешли с 8 ядер на 2 с общим улучшением быстродействия).
давайте по порядку.
Партиции.
В табличке более 500 000 000 записей это информация за 5 лет.
И это не просто табличка в которую делаются insert.
в таблице несколько индексов. Когда идет движение по этой таблице — идет изменение остатков.
Тем не менее благодаря патрициям и субпартициям нет никаких опасений, что через 5 лет придется что-то менять.
Merge существенно ускорил задачи DW. Больше нечего написать.
RESULT_CACHE (Select) (Если грубо — кеширование результата запроса в памяти (для тех кому лень погуглить), с автоматическим пересчетом результата в случае изменения таблиц.)
Поверте ето совсем не то что материализованные вюхи, которые кстати в оракле есть с незапамятних времен)
RESULT_CACHE (Function) Если грубо — кеширование результата запроса функции в памяти (для тех кому лень погуглить), с автоматическим пересчетом результата в случае изменения таблиц, от которых зависит результат функции)
Это настолько крутая фича, что ми ее начали использовать, как только вышел oracle 11R1.(Ми даже пренебрегли золотим правилом использовать новые фичи через релиз.
B конце концов ми нарвались на баг который исправили только 11R2 для нашей платформы)
Самый простой кейс использования в проверке прав пользователя у вюхах(у нас сотни видов объектов в каждом объектов от 10 — до 10 000).
Права как индивидуальнее так и на профили, причем индивидуальнее как на расширении прав так и на сужение.
Чтоб получить результат функции — нужен запрос к нескольким таблицам. (Да, до этого ми использовали кеширование, без него вообще никак)
Благодаря только простой кляузе RESULT_CACHE ми получили более плавный интерфейс, который ощутили все сразу.
Пожалуйста назовите мне аналогичную вещь (для решения данной задачи) в посгри.
Inmemory.(если уж совсем по простому(для тех кому лень погуглить) — табличка размещается в памяти.) Ну да, ето совсем свежая фича. всего то 5 лет ей. :) Я даже не представляю, как объяснить выгоду от нее. Кстати в списке ожидаемых фич посгресовци ее ждут, не так как merge, но все же ждут.
PL/SQL Можно спорить о размещении бизнес логики в БД. Сейчас ето не модно.
Но все же PL/SQL очень бистр. Некоторые вещи я перечислил. Это вообще не полный список, и может даже очень плохой.
P.S. Я написал, что я не эксперт оракл. Ибо чтоб пересчитать реальных экспертов в оракл, наверное, хватит пальцев одной руки.
Как только начинаешь углубляется в детали, понимаешь, что ты не знаешь и 30% возможностей этой БД. Я даже не уверен, что возможно знать хотя б 80% всех возможностей БД.
Я всегда с интересом слежу за выходом новых версий разных БД. Особенно слежу за статьями о посгри. Я всё-таки надеюсь что она выйдет на уровень когда можно будет ее рассматривать как альтернативу ораклу.
И да я писал под разные БД. включая sqlite, mysql, mssql, oracle, И где ето возможно и рационально использовал встроенные языки.
(за плечами многие десятки тысяч строк кода, который работает в продакшене и годами не требует вмешательства) и все равно я не эксперт ни одной БД. А если мне нужно начать работать с новой для меня БД я сначала изучаю нюансы работы этой БД, а только после этого начинаю строить архитектуру БД и писать код.
И да, чуть ли не первое что читаю — это нюанс с null :)
Тем более 2 последних года я больше пишу кода для MsSQL.
И да я уверен, что любую задачу можно решить на любой вменяемой БД.
Вопрос лишь в архитектуре и необходимом усложнении алгоритмов.
Я не религиозный фанатик оракл, я использую БД в зависимости от проекта, наследия, правил и ТД.
Скажу больше било время, когда я любил MySql за простоту и скорость.
P.S.S. Главное что я хотел донести что прокомментировал onix74 ( и собрал наибольше лайков)
https://habr.com/post/422669/#comment_19087833
Я процитирую ""
Переведу как я это понимаю — oracle enterprise и Posgtres ето продукти для разных сегментов.
И низя считать, что Posgtres c лёгкостью заменит oracle enterprise. Если вы с этим согласны — не зря я писал эту статью и угробил карму :)
P.S.S.S. Я в отпуске(слишком поздно промодерировали), и не могу в онлайн комментировать. Некоторые коменти я постараюсь ответить завтра.
И да, всем спасибо за коментарии.
1) RESULT_CACHE
2) Разнообразие Partition, отсутствие SubPartition.(в MsSQL на уровне 8i, в PostgreSQL в десятке прикрутили но до использования в продакшене им пилять и пилять)
3) INMEMORY(опция) — в MsSQL мягко говоря странное, в PostgreSQL нет., Да что говорить в PostgreSQL merge до сих пор нет и не будет в 11.
4) PL/SQL заточен на скорость, масовие обработки, компиляция в нативний код и тд.
Все ето дает прирост быстродействия в на некоторих участках в десятки раз.
Ви можете себе представить перенос дата файла с диска на диск или востановленя «битого блока» в состоянии Online?
А Переход на новие сервера без остановки работи БД?
От таки «маркетинговие» фичи позволяют БД бить в Online годами.
1) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.
2) Простое маштабирование из коробки.
3) Удобство администрирования, отказовоустойчивость и возможность поддерживать систему Online 7*24. И очень многие вещи можно делать без остановки базы.
И да Oracle очень догогой, но если сравнивать не просто стоимость лицензий, а реальную нагрузку, которую держит система то разныци с MsSQL практически не будет.
Для DW можно использовать и MySQL и PostgreSQL.
Я могу сравнивать ибо пишу под MsSQL и Oracle, писал и MySQL и баловался PostgreSQL.
Мы все ето вместе можем легко проверить. Вы предлагаете сценарий БЛ и реализацию JAVA\С#. Я код PL\sql. Желательно что то посложнее, ибо 90% логики можно реализовать оператором (select\merge\update\insert) или их групой. Но сразу оговорим, что задача должна включать многопользовательский режим, и возможность совмесной работы и контроль прав ограничения на даные.
Никогда в таком русле не думал. Всегда смотрел план отдельно в Тоде там ето получше сделано. Согласен прям в дебагере — удобнее.
Я согласен — дебаг и GUI похуже Студии еклипса и тд.
В девелопере достаточно удобная навигация по коду. Ну а портянки ето уже стиль :) а не маст хев. Но ето уже кому что глазу мелее. Мне например не нравится в JAVA\C# многословие в описаниях класа (public, і тд.). Спасибо хотя б в JAVA var добавили :) Наследование, интерфейси итд часто отвлекают от сути, и получается что обертка становится важнее сути. Не подумайте что я не люблю ООП. Я очень любил с++, Сейчас пишу на c#. Но заглянув в grid(C#), я больше не задавался вопросом почему он такой тормознутый. Мне кажется что ето уже слишком. Я понимаю что там все красиво, канонически. Но работать бысто ето не может… Да Я не знаю как сделать так же уневерсально и быстро. Наверно ето и невозможно. Поетому и появлялись пачками самописние grid. Но ето уже другая история.
У меня даже теоретической идеи нет как можно дебажить декларативний язык.
План запроса ето и есть, как по мне, его дебаг. И чуть ли не базис скорости работы.
Я даже скажу больше очень немодно. :) и ета мысль часто жостко минусуется на хабре. Но тем неменее, в целом код написаний на ХП короче аналогичного JAVA\C# значить проще тестится. Проще поддерживается, В случае простых изменений не требует переинстеляции на клиенских машинах. Значит изменения можно внедрять быстрее.
И как я уже писал ниже я не агетирую за БЛ на ХП я агитирую Что выбор Базы и знание нюансов не менне важен за выбор язика програмирования. А по большому счету даже важнее.
Я участвовал в разработках где вся БЛ на БД, и где на БД запрещены ХП (Слава богу хотя foreign key разрешили). Я скажу так, не важно какой путь вы вибрали. Всегда нужно помнить: Каждая БД имеет свой «характер» И то что на MSSQL\Oracle\MySQL\Postgresql\… работает на ура в другой БД может тупить, или вообще не работать. Если у вас OLTP система — не знание етих нюансов ето смерть в продакшине. Я не агетирую за БЛ на БД. Я агитирую за то что разработчик должен знать особенности БД которую будет использовать. И ето значительно важнее для качественного продукта чем знатие всех фич язика или нових фреймворков.
P.S. И да для меня для меня скорость и отзывчевость програмы ето один из главнейших критетеев програмы на равне с юзебилити.
И я видел людей, для которых отритие документа в 1 минуту уже не проблема, они смирились и считают ето нормой. Видя такой софт грусно становится…
Етому есть наверное логичное обеснение.
Согласен. отладка в VS намного удобнее и мощнее.
С етим пунктом я ввел в заблуждение. Можно сказать что отладка присутствует но ограничена.