Если выложить реализацию в паблик, то остаётся только оптимизировать код, это несколько упрощает задачу. Но описать как будет определяться «самая быстрая реализация» было бы не лишним. Какие критерии будут учитываться (время выполнения, потребление памяти, количество операций, визуальный осмотр ващего гуру JS или что-нибудь ещё)?
Может плохие инструменты и есть, но я таких не встречал. Зато встречал инструменты использованные не к месту, в этом случае такой инструмент действительно можно считать плохим, но не объективно, а только в применении к конкретной задаче. Повторюсь ещё раз, объективно плохих инструментов я не встречал, так чтобы они вообще ни на что не годились. И если инструмент устарел — это ещё не делает его плохим, он просто старый.
А если бы они использовали MySQL, вы бы не считали отечественный IT самобытным?
записывать MySQL в «legacy» несколько рановато
Никто его в legacy записывать не собирается, хотя у него много своих причуд и багов (о них писали выше, некоторые баги/причуды исторические и с ними надо просто смириться), и для высоконагруженного проекта я бы его не выбрал.
Но мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQL
И это не означает, что их никогда не было.
Вообще мигрировать с MySQL на MySQL-подобную СУБД проще, чем на PG если не использовалась более-менее нормальная ORM, которая позволит абстрагироваться от проблемы с разными запросами к разным СУБД. А выбор стэка технологий зависит не от «компании», а от людей работающих в ней. Кто сказал, что в крупных компаниях люди делают только правильные выборы? Почему вы считаете, что в крупных компаниях такого результата можно было достингуть только с этим стэком технологий и с другими стэками они никогда не достигли бы таких результатов?
Вообще, если быть уж совсем честным, то всё это всего лишь инструменты и не маловажный фактор тут — на сколько хорошо команда умеет пользоваться этим инструментом. И нельзя делить инструменты на хорошие и плохие, есть только более (или менее) подходящие инструменты для решения какого-то типа/круга задач.
И пусть не получается всю логику всегда хранить в приложении, а СУБД использовать только как хранилище когда эта СУБД может очень хорошо помочь оптимизировать приложение. Допустим вы храните всю логику в приложении, потом натыкаетесь на проблему производительности вашего решения, потом осознаёте, что если переложите эту часть логики на СУБД, то выиграете в скорости и потреблении ресурсов — тогда перестанете думать, что перекладывание логики на СУБД — это какой-то грех. После этого вы просто будете думать как сделать управление логикой на стороне СУБД более удобной, гибкой и не причиняющей боль.
На мой взгляд, MySQL проигрывает PG по ряду причин:
В PG раньше появилась возможность масштабирования «из коробки».
RETURNING, как в MySQL без него живут? Ещё я сталивался с проблемами в MySQL, если там PK это не автоинкрементируемый Integer, а UUID, было это, правда, давно.
WITH — очень хороший помощник в оптимизации запросов к БД, которого нет в MySQL.
PLSQL — отличный инструмент, которого нет в MySQL, даже нет ничего похожего.
Функциональные индексы.
Больше типов данных и можно подключать новые через плагины.
Может и были проблемы, но решал их не я, а кто-то другой из нашей команды. И я не писал, что работал над большим проектом :) «не маленький» !== «большой» :)
Это надо делать крайне редко. А если вы делаете мало UPDATE и DELETE, то, скорее всего, можно вообще без автовакуума обойтись. Проблем с пухнущими индексами не испытывали.
И я раньше натыкался на статьи о том как решать ту или иную проблему в MySQL. Потом удивлялся почему об этих проблемах не пишут про PG, подумал, что мало где используется, хреновое сообщество или люди просто не хотят делиться наработками. А поработав с пол годика с PG понял, что таких проблем там просто нет, поэтому о них никто и не пишет.
Дело было года 3-4 назад, вспомнить с какими проблемами конкретно я сталкивался не получается :( Но помню точно, что их не было при работе с PG.
Мы использовали PG на не маленьком проекте. Проблемы с производительностью были, но все они решались оптимизацией запросов и индексов. Кстати, в плане оптимизации запросов (WITH, например) у PG больше возможностей, да и в плане оптимизации индексов (функциональные индексы, например) — тоже всё лучше, чем в MySQL. Я не уверен, что в MySQL появились функциональные индесы. Или появились?
Лично мои ощущения после перехода с MySQL на PG — ощущение того, что раньше я пользовался какой-то неполноценной СУБД…
Может я чего-то не понимаю, но как, даже в языке с динамической типизцией, 0 == 'Sean' >> true? Как это должно работать под капотом, чтобы получилось true?
Тут всё понятно) Просто жалуюсь) Можно же было сделать по-человечьи сразу :)
Это как и раньше меняется в настройках, при апгрейде вроде бы этот параметр не меняется.
У меня поменялся как-то. У других не менялся… Я особенный, наверно, просто :)
Проблемы с плеером связаны с юзабилити. Пробел должен работать как play/pause, но он далеко не всегда так работает, иногда просто ничего не происходит, а иногда происходит что-то другое (не play/pause). Ещё если на одном мониторе развернуть на весь экран и запустить фильм, то при разворачивании некоторых прог (замечено на utorrent) фильм ставится на паузу. Если в процессе воспроизведения фильма возникла фатальная ошибка, то он не выходит из полноэкранного режима и закрыть плеер — хороший такой квест получается, наверно это можно сделать только через Ctrl+Alt+Delete :)
А я вообще не понял всей фишки с изменением того, что уже было настроено.
Выход из режима гибернации сопровождался вводом пароля, а после обновления пароль вводить не нужно…
Браузер по-умолчанию превратился в тыкву…
Отключение тачпада после присоединения мыши слетело…
Проигрывателем видео файлов был Media Classic Player, после обновления стал дефолтный виндовый новый «афигенный» плеер…
Ещё баги странные, например, если зайти в какую-нибудь директорию в проводнике, перемотать список на низ, потом зайти в ту же директорию через другой проводник и создать файл, то происходят чудеса, причём на разных компах разные… У меня просто список скроллился вверх и иногда он так делает даже если ничего не делать, просто перемотать список и ждать. А у некоторых вообще в другую директорию перебрасывает.
А дефолтный медиа-проигрыватель вообще работает как попало…
Был браузер по-умолчанию = Chrome. Обновился с 8 до 10 и меня никто не спрашивал какой браузер я хочу по-умолчанию, просто поставили Edge везде. Спасибо хоть Chrome при обновлении не удалили :)
Но это ни о чём не говорит.
Никто его в legacy записывать не собирается, хотя у него много своих причуд и багов (о них писали выше, некоторые баги/причуды исторические и с ними надо просто смириться), и для высоконагруженного проекта я бы его не выбрал.
Вообще мигрировать с MySQL на MySQL-подобную СУБД проще, чем на PG если не использовалась более-менее нормальная ORM, которая позволит абстрагироваться от проблемы с разными запросами к разным СУБД. А выбор стэка технологий зависит не от «компании», а от людей работающих в ней. Кто сказал, что в крупных компаниях люди делают только правильные выборы? Почему вы считаете, что в крупных компаниях такого результата можно было достингуть только с этим стэком технологий и с другими стэками они никогда не достигли бы таких результатов?
Вообще, если быть уж совсем честным, то всё это всего лишь инструменты и не маловажный фактор тут — на сколько хорошо команда умеет пользоваться этим инструментом. И нельзя делить инструменты на хорошие и плохие, есть только более (или менее) подходящие инструменты для решения какого-то типа/круга задач.
И пусть не получается всю логику всегда хранить в приложении, а СУБД использовать только как хранилище когда эта СУБД может очень хорошо помочь оптимизировать приложение. Допустим вы храните всю логику в приложении, потом натыкаетесь на проблему производительности вашего решения, потом осознаёте, что если переложите эту часть логики на СУБД, то выиграете в скорости и потреблении ресурсов — тогда перестанете думать, что перекладывание логики на СУБД — это какой-то грех. После этого вы просто будете думать как сделать управление логикой на стороне СУБД более удобной, гибкой и не причиняющей боль.
Дело было года 3-4 назад, вспомнить с какими проблемами конкретно я сталкивался не получается :( Но помню точно, что их не было при работе с PG.
Лично мои ощущения после перехода с MySQL на PG — ощущение того, что раньше я пользовался какой-то неполноценной СУБД…
А как должно работать в JS я понимаю и, как следствие, понимаю почему там false получается :)
У меня поменялся как-то. У других не менялся… Я особенный, наверно, просто :)
Проблемы с плеером связаны с юзабилити. Пробел должен работать как play/pause, но он далеко не всегда так работает, иногда просто ничего не происходит, а иногда происходит что-то другое (не play/pause). Ещё если на одном мониторе развернуть на весь экран и запустить фильм, то при разворачивании некоторых прог (замечено на utorrent) фильм ставится на паузу. Если в процессе воспроизведения фильма возникла фатальная ошибка, то он не выходит из полноэкранного режима и закрыть плеер — хороший такой квест получается, наверно это можно сделать только через Ctrl+Alt+Delete :)
Выход из режима гибернации сопровождался вводом пароля, а после обновления пароль вводить не нужно…
Браузер по-умолчанию превратился в тыкву…
Отключение тачпада после присоединения мыши слетело…
Проигрывателем видео файлов был Media Classic Player, после обновления стал дефолтный виндовый новый «афигенный» плеер…
Ещё баги странные, например, если зайти в какую-нибудь директорию в проводнике, перемотать список на низ, потом зайти в ту же директорию через другой проводник и создать файл, то происходят чудеса, причём на разных компах разные… У меня просто список скроллился вверх и иногда он так делает даже если ничего не делать, просто перемотать список и ждать. А у некоторых вообще в другую директорию перебрасывает.
А дефолтный медиа-проигрыватель вообще работает как попало…