ReSQL.ru
     
powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Наши за рубежом [закрыт для гостей] / Что происходит на рынке DB вакансий в ЕС?
25 сообщений из 375, страница 12 из 15
  12  все
Что происходит на рынке DB вакансий в ЕС?
    #21633761
yabs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yabs
Участник
stenford,

И почему замена хранимки по определению не оттестирована?!
...
Рейтинг: 0 / 0
08.08.2018, 08:25
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633774
jbond81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jbond81
Участник
Wizandr 
jbond81 
пропущено...

Стоимость внесения изменений стремится к бесконечности.
дык наоборот же
открыл хранимку внес изменения
даже деплоить ничего не нужно :)
У нас часть проекта провалилась из-за того, что логика формирования XML по куче связанных таблиц была написана на извините за выражение PL SQL.

Этот человек допустил ошибку в коде (missing feature support) и никто из участников проекта не смог доработать в указанном объеме код хранимки из-за ее сложности и плохой документирование ( отсутствие инфраструктуры для тестирования и отладки).

Сейчас этот человек ушел из проекта, мы пользуемся врапперами над сторонним Ява коде, использующие ORM, эту ХП никто не использует
...
Рейтинг: 0 / 0
08.08.2018, 08:36
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633790
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OoCc
Участник
jbond81 
Wizandr 
пропущено...

дык наоборот же
открыл хранимку внес изменения
даже деплоить ничего не нужно :)
У нас часть проекта провалилась из-за того, что логика формирования XML по куче связанных таблиц была написана на извините за выражение PL SQL.

Этот человек допустил ошибку в коде (missing feature support) и никто из участников проекта не смог доработать в указанном объеме код хранимки из-за ее сложности и плохой документирование ( отсутствие инфраструктуры для тестирования и отладки).

Сейчас этот человек ушел из проекта, мы пользуемся врапперами над сторонним Ява коде, использующие ORM, эту ХП никто не использует
Это всего лишь говорит о бар**ке в вашей конторе.
...
Рейтинг: 0 / 0
08.08.2018, 09:15
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633803
Stan2000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stan2000
Участник
OoCc 
Это всего лишь говорит о бар**ке в вашей конторе.
+100500 и дебиле ПМ и жадности и нежелании платить SQL Dev. Взяли бы на несколько часов фрилансера, кто пофиксит.
...
Рейтинг: 0 / 0
08.08.2018, 09:25
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633809
Stan2000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stan2000
Участник
Вообще с развитием новых стильных, молодежных технологий сейчас принято выгрузить 100500 млн строк и в бэкекнде это отсортировать модным методом быстрой сортировки. Мне так недавно и заявили, что это теперь так делается не надо никаких БД и индексов для этого, есть паттерны специальные. я аж прифигел немного. Жаль что команду не я себе выбирал.
...
Рейтинг: 0 / 0
08.08.2018, 09:32
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633811
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
yabs 
В кто говорил про аппсервер?
двухзвенка с толстыми клиентами? Там конечно хранимки, ДБА и полный набор из начала 2000-х
...
Рейтинг: 0 / 0
08.08.2018, 09:33
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633821
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
Stan2000 
+100500 и дебиле ПМ и жадности и нежелании платить SQL Dev. Взяли бы на несколько часов фрилансера, кто пофиксит.
если дешевле заюзать сторонний враппер с ORM, за зачем платить фрилансеру? А потом когда окажется что надо чинить то, что наделал этот фрилансер - нанимать еще одного?
...
Рейтинг: 0 / 0
08.08.2018, 09:41
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21633999
Stan2000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stan2000
Участник
stenford 
Stan2000 
+100500 и дебиле ПМ и жадности и нежелании платить SQL Dev. Взяли бы на несколько часов фрилансера, кто пофиксит.
если дешевле заюзать сторонний враппер с ORM, за зачем платить фрилансеру? А потом когда окажется что надо чинить то, что наделал этот фрилансер - нанимать еще одного?
часть проекта бы не провалилась, если бы можно бы было использовать ОРМ изначально, значит было что-то сложнее, что ОРМ не может сделать. У меня было много халтурок на odesk где надо было ускорить запрос, иногда надо было сделать правильно индексы, иногда можно было обойтись matview, часто, просто надо было переписать запрос. скорость увеличивалась в десятки и сотни раз.
поэтому, пока у вас приложение имеет миллион строк в БД и 20 клиентов с некритическими данными, вам не нуден ДБА, а вот когда буде тысяча-10 тысяч таблиц по 100500 миллионов записей с критическими данными, тогда подумаете.
а вообще все это до первого раза, когда потеряете критические данные, пока это не критично, этим занимаются девелоперы и ОРМ.
такое тоже 100 раз видел, в том числе на этом форуме.
...
Рейтинг: 0 / 0
08.08.2018, 10:52
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21634006
Stan2000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stan2000
Участник
в одной большой нефте-газовой компании потеряли данные за пару месяцев работы одного из департаментов научного центра. стоимость работы и потерянных данных и сорванных сроков по проекту стоили охулиард денег. после этого при слове бэкап, шеф подписывал любые бумаги на покупку оборудования и софта. ну и я тогда туда попал как ДБА :)
...
Рейтинг: 0 / 0
08.08.2018, 10:56
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21634027
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
stenford 
Megabyte 
Когда клиентов в таблице 100-1000, то да, код ОРМ будет немного проще. Я согласен, что можно и ОРМ заюзать.

А если разобрать другую ситуацию: таблица, например, 100млн транзакций. Будешь ли ты обращаться к ней по какому угодно фильтру то, на выбор:
1) будешь жрать ресурсы на скан таблицы и мешать другим пользователям, если не положишь систему в целом.
2) натыкаешь индексов на все возможные поля и поимеешь производительность на вставку\апдейт\удаление записи.

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

С хп такой финт ушами не пройдет, надо будет сначала произвести доработку процы, внедрить параметр, или сделать новую процу.
Но на сервере можно же и разграничить доступ в том числе и для программистов, чтоб не делали всякую хрень без проверки ДБА. :)
то, что для хранимки потребуется больше работы (новый параметр или новая хранимка) никак не обезопасит систему. Если разработчик запулил запрос по полю без индексов - то это проблема безотносительна хранимок или ORM, это вина разработчика, и только его. В случае хранимок никакой ДБА его не спасет - на практике они никогда не проверяют код перед коммитом в систему, да и бессмысленно это будет в большинстве случаев, ДБА тоже легко может пропустить такую ошибку если ему свалить на код ревью десятки хранимок в день сделанные разработчиками. Такие проблемы решаются не привлечением ДБА, а элементарым нагрузочным тестированием, скан таблицы мгновенно всплывет в тесте и будет зафиксен. На самом деле даже раньше т.к. в грамотно поставленном процессе разработчик до коммита сначала проверит что за план у него сгенерился и словит скан даже на небольшой таблице
1) Мой пример показывал абсурдность постановки вопроса "А вот я в ОРМ захочу по такому полю отфильтровать" (с) Варианты доступа до больших и высоконагруженных таблиц должны заранее обговариваться!
Просто так навесить еще один индекс по хотелке какого-то разрабочика - это тоже не совсем правильно.

2) Хорошему ДБА для поиска и мониторинга проблемных запросов не надо проверять все хранимки, достаточно выполнить несколько запросов по системным данным. Код ревью всех хранимок - это не совсем правильное использование времени ДБА.

У меня на фирме все разрабы пишут запросы\хп, но оптимизирую их, в основном, я один, ну либо разрабы по моим рекомендациям. Да я бы все время тогда тратил на код ревью. Ниче, практически все проблемы диагностируются либо автоматически, либо полуавтоматически, запуском разных запросов. Ну и ревьюить хп, где select * from table с < 1000 записей точно не имеет смысла.

3) Насчет проверки кода самим разрабом. Ну, во-первых, хорошими знаниями по SQL обладает гораздо меньше людей. На моей практике, фанаты ОРМ SQL знают на очень примитивном уровне, даже про индексы, бывало, не слышали. Ну и когда, допустим, запускается новый проект, в таблице 1.5 сотни записей. Все, конечно же, летает. Скан таблицы сам по себе - это не есть неправильно. Все же зависит от объема данных, от задачи. На этапе разработки можно и не знать, как будет в итоге юзаться таблица, какие по ней отчеты будут строиться.
...
Рейтинг: 0 / 0
08.08.2018, 11:08
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21634031
Фотография Wizandr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Wizandr
Участник
если нужно генерить сложный XML то что мешает допустить ошибку при использовании ORM?
сложная логика всерано останется сложно хойть на уровне БД хоть на уровне сервера приложений
...
Рейтинг: 0 / 0
08.08.2018, 11:10
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21634042
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Stan2000 
stenford 
пропущено...

если дешевле заюзать сторонний враппер с ORM, за зачем платить фрилансеру? А потом когда окажется что надо чинить то, что наделал этот фрилансер - нанимать еще одного?
часть проекта бы не провалилась, если бы можно бы было использовать ОРМ изначально, значит было что-то сложнее, что ОРМ не может сделать. У меня было много халтурок на odesk где надо было ускорить запрос, иногда надо было сделать правильно индексы, иногда можно было обойтись matview, часто, просто надо было переписать запрос. скорость увеличивалась в десятки и сотни раз.
поэтому, пока у вас приложение имеет миллион строк в БД и 20 клиентов с некритическими данными, вам не нуден ДБА, а вот когда буде тысяча-10 тысяч таблиц по 100500 миллионов записей с критическими данными, тогда подумаете.
а вообще все это до первого раза, когда потеряете критические данные, пока это не критично, этим занимаются девелоперы и ОРМ.
такое тоже 100 раз видел, в том числе на этом форуме.
+1

У меня был на зарубежном фрилансе вообще уникальный случай. Требовалось оптимизировать запросы на этапе разработки!!! Запросы выполнялись больше минуты, хотя самая большая таблица была на 37 тысяч строк.
Заказ был от менеджера. Я глянул несколько запросов разработчика - это трэш, угар и содомия. Видно, что разработчик - фанат ООП и пытается применить ООП в SQL. Он понаделал вьюх со сложным внутренним кодом. Это у него, как я понимаю, были объекты-сущности, а потом еще соединял в запросах между собой. В итоге у него эта самая таблица на 37 тысяч строк перемножалась сама с собой, т.к. была заюзана в 2х разных вьюхах, соединенных в запросе.
В итоге вместо оптимизации, ибо там надо было переделывать все(!), писал рекомендации разработчику, как писать код на SQL.
...
Рейтинг: 0 / 0
08.08.2018, 11:19
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21635087
yabs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yabs
Участник
Stan2000 
stenford 
пропущено...

если дешевле заюзать сторонний враппер с ORM, за зачем платить фрилансеру? А потом когда окажется что надо чинить то, что наделал этот фрилансер - нанимать еще одного?
часть проекта бы не провалилась, если бы можно бы было использовать ОРМ изначально, значит было что-то сложнее, что ОРМ не может сделать. У меня было много халтурок на odesk где надо было ускорить запрос, иногда надо было сделать правильно индексы, иногда можно было обойтись matview, часто, просто надо было переписать запрос. скорость увеличивалась в десятки и сотни раз.
поэтому, пока у вас приложение имеет миллион строк в БД и 20 клиентов с некритическими данными, вам не нуден ДБА, а вот когда буде тысяча-10 тысяч таблиц по 100500 миллионов записей с критическими данными, тогда подумаете.
а вообще все это до первого раза, когда потеряете критические данные, пока это не критично, этим занимаются девелоперы и ОРМ.
такое тоже 100 раз видел, в том числе на этом форуме.
У меня порой складывается ощущение, что многие из тех, кто топит за хранимки, современные ОРМы видел сильно издалека.
ОРМ не запрещает использование ни вьюшек ни индексов.
И уж точно под ОРМ не легче похерить критические данные.
...
Рейтинг: 0 / 0
08.08.2018, 22:30
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21635238
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
Stan2000 
поэтому, пока у вас приложение имеет миллион строк в БД и 20 клиентов с некритическими данными, вам не нуден ДБА, а вот когда буде тысяча-10 тысяч таблиц по 100500 миллионов записей с критическими данными, тогда подумаете.
а вообще все это до первого раза, когда потеряете критические данные, пока это не критично, этим занимаются девелоперы и ОРМ.
такое тоже 100 раз видел, в том числе на этом форуме.
хоть триллион таблиц с триллионом записей. ORM не может иметь никакого отношения к проблемам производительности по определению т.к. генерируемый код не уступает написанному вручную. Это очень устойчивый миф про тормоза ORM'ов, но вызывзющийу лишь смех у разработчиков реально с ними работающих.
...
Рейтинг: 0 / 0
09.08.2018, 01:38
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21635245
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
Megabyte 
1) Мой пример показывал абсурдность постановки вопроса "А вот я в ОРМ захочу по такому полю отфильтровать" (с) Варианты доступа до больших и высоконагруженных таблиц должны заранее обговариваться!
ну так обговаривайте, причем здесь ORM/не ORM?
Megabyte 
2) Хорошему ДБА для поиска и мониторинга проблемных запросов не надо проверять все хранимки, достаточно выполнить несколько запросов по системным данным.
какие именно данные вы смотрите?
Megabyte 
3) Насчет проверки кода самим разрабом. Ну, во-первых, хорошими знаниями по SQL обладает гораздо меньше людей. На моей практике, фанаты ОРМ SQL знают на очень примитивном уровне, даже про индексы, бывало, не слышали. Ну и когда, допустим, запускается новый проект, в таблице 1.5 сотни записей. Все, конечно же, летает. Скан таблицы сам по себе - это не есть неправильно. Все же зависит от объема данных, от задачи. На этапе разработки можно и не знать, как будет в итоге юзаться таблица, какие по ней отчеты будут строиться.
есть такое современое понятие как full stack разработчики. Знание sql и баз данных на определенном уровне уже давно часть квалификации нормального программиста. Найти работу без знания баз данных сейчас можно только как front end разработчик, т.е. по-сути клепая дезайн веб страниц. Я еще раз повторю, что при современном подходе к разработке тормозные запросы просто не пройдут в продакш, они будут как минимум выявлены на стадии нагрузочного тестирования. Все эти хранимые процедуры с ДБА в роли спасителей давно в прошлом. Для написания ORM запросов не требуется каких-то специфических познаний, т.к. сами запросы не являются чем-то сложным.
Во времена хранимых процедур такие знания действительно были нужны т.к. вся логика содержалась там и писать ХП в сотни строк с навороченными запросами было нормой. Конечно присмотр эксперта в базах был необходим (да и тестирования в те времена особого не было).
Я бы пошел еще дальше и сказал что средний выхлоп системы на ORM сейчас выше, чем на хранимках, хотя-бы потому, что несколько несложных точечных запросов куда производительнее, чем навороченные переоптимизированные хранимки в сотни/тысячи строк в которых потом никто не может разобраться (да еще и с планом оптимизированным на первый запрос, если конечно не рекомпилить ее каждый раз)
...
Рейтинг: 0 / 0
09.08.2018, 02:08
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21635249
jbond81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jbond81
Участник
Stan2000 
OoCc 
Это всего лишь говорит о бар**ке в вашей конторе.
+100500 и дебиле ПМ и жадности и нежелании платить SQL Dev. Взяли бы на несколько часов фрилансера, кто пофиксит.
Человек, который написал так код и был фрилансером.

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

зы. Он отказался сам красить свой баг. В конце концов сбежал из проекта. А нам фиксам дальше проект пилить.
...
Рейтинг: 0 / 0
09.08.2018, 02:30
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21635561
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
stenford 
да еще и с планом оптимизированным на первый запрос, если конечно не рекомпилить ее каждый раз
А это, простите, о чём? Мусьё не в курсе как работают оптимизаторы СУБД?
...
Рейтинг: 0 / 0
09.08.2018, 10:57
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21636255
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
stenford 
Megabyte 
1) Мой пример показывал абсурдность постановки вопроса "А вот я в ОРМ захочу по такому полю отфильтровать" (с) Варианты доступа до больших и высоконагруженных таблиц должны заранее обговариваться!
1) ну так обговаривайте, причем здесь ORM/не ORM?
Megabyte 
2) Хорошему ДБА для поиска и мониторинга проблемных запросов не надо проверять все хранимки, достаточно выполнить несколько запросов по системным данным.
2) какие именно данные вы смотрите?
Megabyte 
3) Насчет проверки кода самим разрабом. Ну, во-первых, хорошими знаниями по SQL обладает гораздо меньше людей. На моей практике, фанаты ОРМ SQL знают на очень примитивном уровне, даже про индексы, бывало, не слышали. Ну и когда, допустим, запускается новый проект, в таблице 1.5 сотни записей. Все, конечно же, летает. Скан таблицы сам по себе - это не есть неправильно. Все же зависит от объема данных, от задачи. На этапе разработки можно и не знать, как будет в итоге юзаться таблица, какие по ней отчеты будут строиться.
3) есть такое современое понятие как full stack разработчики. Знание sql и баз данных на определенном уровне уже давно часть квалификации нормального программиста. Найти работу без знания баз данных сейчас можно только как front end разработчик, т.е. по-сути клепая дезайн веб страниц. Я еще раз повторю, что при современном подходе к разработке тормозные запросы просто не пройдут в продакш, они будут как минимум выявлены на стадии нагрузочного тестирования.

4) Все эти хранимые процедуры с ДБА в роли спасителей давно в прошлом. Для написания ORM запросов не требуется каких-то специфических познаний, т.к. сами запросы не являются чем-то сложным.
Во времена хранимых процедур такие знания действительно были нужны т.к. вся логика содержалась там и писать ХП в сотни строк с навороченными запросами было нормой. Конечно присмотр эксперта в базах был необходим (да и тестирования в те времена особого не было).

5) Я бы пошел еще дальше и сказал что средний выхлоп системы на ORM сейчас выше, чем на хранимках, хотя-бы потому, что несколько несложных точечных запросов куда производительнее, чем навороченные переоптимизированные хранимки в сотни/тысячи строк в которых потом никто не может разобраться (да еще и с планом оптимизированным на первый запрос, если конечно не рекомпилить ее каждый раз)
1) Еще раз повторю, что это был ответ на ваш комментарий про то, что: "А вот разрабочик захочет по такому фильтру(кол-во детей) отфильтроовать. На SQL это надо новый параметр или новую процу, а в коде с использованием ОРМ все просто". Получается, что никакого смысла в этой реплике нет в общем случае и данный вариант подходит только для маленьких таблиц. И я согласился, что здесь можно юзать ОРМ.

2) По статистике: необходимые индексы\неиспользуемые индексы; запросы, которые больше всего грузят ЦПУ; запросы, которые больше всего грузят диск; какие типы блокировок(для MS SQL) преобладают, чтобы понять, куда копать; монитор текущих запросов.

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

4) У вас на фирме - в это я поверю. Однако в реальности все гораздо сложнее. :) Революции ОРМ не сделали, так, заняли какую-то свою нишу. Я так вообще наблюдаю рост запросов на ДБА, в и постоянных вакухах, и на фрилансе.

5) Как меряли производительность? И это, никто не сказал, что в SQL\хп можно наговнокодить. Такое есть, безусловно.
Ну и да, в скобках бред какой-то написан, вам уже сообщили...
...
Рейтинг: 0 / 0
09.08.2018, 15:04
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21636521
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
М-да, начинаю понимать зачем нужен DevOps
Некоторые девелоперы категорически не хотят понимать специфику работы Operations.
stenford 
Я еще раз повторю, что при современном подходе к разработке тормозные запросы просто не пройдут в продакш, они будут как минимум выявлены на стадии нагрузочного тестирования
Я бизнес, у меня есть приложение, купленое от вендора, я понятия не имею, как оно прошло нагрузочное тестирование, было ли оно сделано с помощью ORM, двухзвенка или трехзвенка или еще как. Важно что оно делает то что мне нужно и на момент покупки все было хорошо, сейчас стало тормозить.
Два вопроса: кто виноват, что делать.
Правильный ответ:
Виноват вендор, обращаемся в техподдержку, описываем проблему, разработчик находит баг, высылает патч все довольны.
Вопрос: как часто проблемы решаются по этому сценарию?
Более популярный сценарий:
Виноват начальник IT - подсунул какую-то туфту, наверняка еще откат поимел, делай что хочешь, но все должно работать хорошо.
Что делать - обратится к вендору.
Ответы разработчика -
1 ваш баг воспроизвести не удалось, у меня все хорошо, присылайте базу.
Бизнес - свою много гигабайтную базу мы прислать не можем, ибо там секретные данные. Сделайте что-нибудь.
2 Ага, проблема имеет место быть и будет исправлена в следующей версии.
Бизнес - переход на следующую версию не планируется в этом году. Сделайте что-нибудь.
3 Ваша версия не поддерживается. Но у нас есть другой продукт, который будет делать тоже самое и даже лучше.
Бизнес - смотри предыдущий пункт.
3 Разработчик - патч специально для вас будет стоить ХХХ у.е.
Бизнес - да вы охренели что-ли. Сделайте что-нибудь.
stenford 
Это очень устойчивый миф про тормоза ORM'ов, но вызывзющийу лишь смех у разработчиков реально с ними работающих.
Никогда не задумывались - почему этот миф столь устойчив, у людей реально работающих с самыми разными системами: старыми и новыми, сделаными с ORM и без.
Наверное, потому что для вас разработчики замечательные люди, которые тщательно тестируют свои продукты, а админы - тупоголовые дубы. Причем я допускаю, что есть разные разработчики, вменяемые и нет, а для вас наличие вменяемых админов просто нонсенс, админы должны быть истреблены как класс, ну или вымереть как динозавры.
stenford 
несколько несложных точечных запросов куда производительнее, чем навороченные переоптимизированные хранимки в сотни/тысячи строк в которых потом никто не может разобраться
И ведь вам даже в голову не приходит задуматся - откуда появляются навороченные переоптимизированные хранимки. Мазохисты их какие-то так пишут, небось боятся, чтобы их не уволили. Заменить надо старую систему у нее пепельница переполнилась вот как раз новый продукт вышел.
...
Рейтинг: 0 / 0
09.08.2018, 17:31
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21636538
Фотография burgos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
burgos
Участник
SERG1257,

Сценарии описаны превосходно! Так оно все и есть. И это я говорю, как разработчик. :)))
Правда в моем конкретном случае, мы разрабатываем всё, включая базу данных.
...
Рейтинг: 0 / 0
09.08.2018, 17:50
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21636558
sergeyns
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sergeyns
Участник
SERG1257 
Более популярный сценарий:
Виноват начальник IT - подсунул какую-то туфту, наверняка еще откат поимел, делай что хочешь, но все должно работать хорошо.
Что делать - обратится к вендору.
Ответы разработчика -
1 ваш баг воспроизвести не удалось, у меня все хорошо, присылайте базу.
Бизнес - свою много гигабайтную базу мы прислать не можем, ибо там секретные данные. Сделайте что-нибудь.
2 Ага, проблема имеет место быть и будет исправлена в следующей версии.
Бизнес - переход на следующую версию не планируется в этом году. Сделайте что-нибудь.
3 Ваша версия не поддерживается. Но у нас есть другой продукт, который будет делать тоже самое и даже лучше.
Бизнес - смотри предыдущий пункт.
3 Разработчик - патч специально для вас будет стоить ХХХ у.е.
Бизнес - да вы охренели что-ли. Сделайте что-нибудь.
еще есть
0. На оплату суппорта забили, тк зачем платить 20-25% от стоимости софта каждый год, если оно и так работает?
...
Рейтинг: 0 / 0
09.08.2018, 18:11
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21636560
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
burgos 
мы разрабатываем всё, включая базу данных.
А кто еще будет разрабатывать базу данных, админ что-ли?
Повторю за alexeyvg - у меня складывается впечатление, что современные продвинутые разработчики относятся к СУБД как к чему-то противному, старому и вонючему, что надо трогать только в перчатках через ORM, а если кто напрямую залез в базу, разобрался в SQL что то там оптимизировал, то это зашквар, такому руки не подают.
Настоящий разработчик, (тот самый что не использует паскаль) должен написать свою собственную базу.
...
Рейтинг: 0 / 0
09.08.2018, 18:13
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21636564
Фотография burgos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
burgos
Участник
sergeyns 
SERG1257 
Более популярный сценарий:
Виноват начальник IT - подсунул какую-то туфту, наверняка еще откат поимел, делай что хочешь, но все должно работать хорошо.
Что делать - обратится к вендору.
Ответы разработчика -
1 ваш баг воспроизвести не удалось, у меня все хорошо, присылайте базу.
Бизнес - свою много гигабайтную базу мы прислать не можем, ибо там секретные данные. Сделайте что-нибудь.
2 Ага, проблема имеет место быть и будет исправлена в следующей версии.
Бизнес - переход на следующую версию не планируется в этом году. Сделайте что-нибудь.
3 Ваша версия не поддерживается. Но у нас есть другой продукт, который будет делать тоже самое и даже лучше.
Бизнес - смотри предыдущий пункт.
3 Разработчик - патч специально для вас будет стоить ХХХ у.е.
Бизнес - да вы охренели что-ли. Сделайте что-нибудь.
еще есть
0. На оплату суппорта забили, тк зачем платить 20-25% от стоимости софта каждый год, если оно и так работает?
Ну с этим бороться очень просто. Впиливаешь за решение проблемы стоимость годовой поддержки плюс 50% и прозрачно намекаешь, что в случае суппорта это было бы сделано бесплатно. :)))
...
Рейтинг: 0 / 0
09.08.2018, 18:19
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21636791
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Shtock 
А это, простите, о чём?
Это parameter sniffing - пренеприятнейшая штучка
https://www.brentozar.com/archive/2013/06/the-elephant-and-the-mouse-or-parameter-sniffing-in-sql-server/
...
Рейтинг: 0 / 0
09.08.2018, 21:10
| Ответить | Цитировать | Написать  
Что происходит на рынке DB вакансий в ЕС?
    #21637065
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
Megabyte 
1) Еще раз повторю, что это был ответ на ваш комментарий про то, что: "А вот разрабочик захочет по такому фильтру(кол-во детей) отфильтроовать. На SQL это надо новый параметр или новую процу, а в коде с использованием ОРМ все просто". Получается, что никакого смысла в этой реплике нет в общем случае и данный вариант подходит только для маленьких таблиц. И я согласился, что здесь можно юзать ОРМ.
Ну да, в ОРМ все просто, не надо ни ХП ни параметров не перетестирования кода, где вы тут противоречие-то увидели? Захотел - отфильтровал. Это не значит что про индекс забыл/не знал, с чего-бы? У разработчика есть спецификация, где время отклика оговорено (обычно). Если запрос без индекса не уложился - то индекс будет добавлен в список предложений по изменению схемы. Каким образом доп. работа по написанию ХП, новых DAL методов и тестов все это улучшит?
Megabyte 
2) По статистике: необходимые индексы\неиспользуемые индексы; запросы, которые больше всего грузят ЦПУ; запросы, которые больше всего грузят диск; какие типы блокировок(для MS SQL) преобладают, чтобы понять, куда копать; монитор текущих запросов.
ok, cool, что мешает вам делать все то-же самое для запросов идущих от ОRМ?
Megabyte 
3) Как правило, фулл стэк разрабочики - это как аникейщики, знают все в среднем\плохо и какую-то одну область хорошо. У нас на фирме тоже, считай, все фулл стэк, запросы пишут к базе и т.п., но по факту оптимизацией кода за всех занимаюсь я один.
Из остальных, один хорошо шарит по бизнес-процессам, другой со всякими апи\джон на ты, третий хорошо пишет скрипты - сценарии на нашем ПО и т.д. Специализация - это двигатель производительности. Невозможно сразу везде быть спецом, за редким исключением.
я согласен, и часто специализацияи все-же имеет место быть, те-же front-end девелоперы, однако отдельного спеца по написанию запросов через ORM точно не требуется, я уже писал что сами запросы там относительно несложные, вся навороченная бизнес-логика уехала на аппсервер, все что ORM делает - это достает необходимые данные, ничего супер сложного там нет. Что-бы оптимизировать такие запросы специфических знаний не требуется, а если и попадается что-то необычное - то разработчик сядет и разберется, работа такая, я каждый день решаю задачи на которые не знаю ответа сходу
Megabyte 
Я так вообще наблюдаю рост запросов на ДБА, в и постоянных вакухах, и на фрилансе.
это вы еще не видели рост запросов на full stack dev'ов ;)
Megabyte 
5) Как меряли производительность? И это, никто не сказал, что в SQL\хп можно наговнокодить. Такое есть, безусловно.
Ну и да, в скобках бред какой-то написан, вам уже сообщили...
не мерял, интуиция просто. В скобках написан не бред, а тот очевидный факт что план исполнения хранимок (как вы должны быть в курсе) компилится на первом ее вызове для параметров этого вызова. То-же самое для запросов от ОРМ, но с той разницей что когда у вас хранимка в сотни строк, с ветвлением по массе условий и прочего - то good luck получить там оптимальный план на последующие вызовы
...
Рейтинг: 0 / 0
10.08.2018, 02:07
| Ответить | Цитировать | Написать  
25 сообщений из 375, страница 12 из 15
  12  все
Форумы / Наши за рубежом [закрыт для гостей] / Что происходит на рынке DB вакансий в ЕС?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=7&msg=21634042&tid=1297162]:
 0ms
get settings:
 17ms
get forum list:
 5ms
check forum access:
 1ms
check topic access:
 1ms
track hit:
 32ms
get topic data:
 3ms
get forum data:
 1ms
get page messages:
 411ms
get tp. blocked users:
 1ms
others: 286ms
total:  758ms
созд. / загр.: 758ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]