Что случилось с сиквельными скиллзами за последние годы?

[Aleksey Kudinov]

С десяток лет назад, когда trees were tall and we were small и я ещё код пописывал, так нормальный жаба-девелопер всегда приходил с вполне неплохими db-skills, хотя бы какой sql-flavor, неважно. Сейчас же идут косяком вполне хорошие спецы с жабой и сиквелом чуть больше нуля, причём в резюме - сиквель сервер, оракль, майсиквель и прочий букет заболеваний.

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

[АццкоМото]

кому сейчас нахрен нужно знать об SQL что-то больше, чем SELECT * FROM PEOPLE WHERE DEPARTMENT_ID = 7 ?
впрочем, кому нахрен нужны в 2016 году матерые дибиэйщики - не менее занятный вопрос

[mskmel]

Что случилось в корп секторе, что дб-скиллзы оказались в таком загоне?

ORM

[fruit6]

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

[Aleksey Kudinov]

Что случилось в корп секторе, что дб-скиллзы оказались в таком загоне?

ORM

Ну всякие Hibernate и iBatis уже долго по свету хаживают. И никто так и не решил главной проблемы по вашей же ссылке:

Disadvantages of ORM tools generally stem from the high level of abstraction obscuring what is actually happening in the implementation code. Also, heavy reliance on ORM software has been cited as a major factor in producing poorly designed databases.

[Aleksey Kudinov]

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

То есть DB не входит в full stack development?
И потом, это ж сколько отдельно-проверенных людей нужно содержать, чтобы писать многочисленные корпоративные сервисы?

[fruit6]

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

То есть DB не входит в full stack development?

Зависит от того какие задачи вы пытаетесь решить с помощью найма раб силы.

Если обычный стандартный апп с ГУИ, апп сервером, базкой, то да, "full stack" значит знание sql на уровне ORM. Высший пилотаж -- умение настраивать кеширование в сервисе, и решать типичные проблемы. Full stack еще значит что человеку можно поручить задачу и он ее как бы сам решит.

[АццкоМото]

Full stack, imho, совершенно бессмысленный набор букв. Может означать что угодно

[Easbayguy]

С десяток лет назад, когда trees were tall and we were small и я ещё код пописывал, так нормальный жаба-девелопер всегда приходил с вполне неплохими db-skills, хотя бы какой sql-flavor, неважно. Сейчас же идут косяком вполне хорошие спецы с жабой и сиквелом чуть больше нуля, причём в резюме - сиквель сервер, оракль, майсиквель и прочий букет заболеваний.

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

Денормализация данных и шардинг на десятки маленьких/средних баз. Развитие всяких memcache/reddis/etc, in memory databases. И главное обилие данных которые не требуют транзакционных баз и могут быть легко потеряны быз глобальных проблем логи/клики/блоги/etc. Значительно удешевление железа на фоне дорогих oracle/MSSQL лицензий. Огромное количество стартапов просто не доживает до больших обьемов данных и смысла тратить ресурсы на back end нету.
Даже в корпоративном секторе новые проекты пытаются использовать новые технологии.

[major Major Major Major]

кому сейчас нахрен нужно знать об SQL что-то больше, чем SELECT * FROM PEOPLE WHERE DEPARTMENT_ID = 7 ?
впрочем, кому нахрен нужны в 2016 году матерые дибиэйщики - не менее занятный вопрос

Не так, кому нужно знать что то больше чем context.People.Where(p => p.DepartmentID == 7).
Согласен с предыдущим оратором - ORMы достигли высокой степени насыщения, народ в массе не понимает что там идет на сервер. Многие (из интервью вынес) вообще не понимают что в результате генериться sql запрос. Честно-честно.

А кому нужны DBA - так любой конторе с Ораклом Oracle DBA это 5 колонна Оракла в вашем датацентре.

[АццкоМото]

кому сейчас нахрен нужно знать об SQL что-то больше, чем SELECT * FROM PEOPLE WHERE DEPARTMENT_ID = 7 ?
впрочем, кому нахрен нужны в 2016 году матерые дибиэйщики - не менее занятный вопрос

Не так, кому нужно знать что то больше чем context.People.Where(p => p.DepartmentID == 7).
Согласен с предыдущим оратором - ORMы достигли высокой степени насыщения, народ в массе не понимает что там идет на сервер. Многие (из интервью вынес) вообще не понимают что в результате генериться sql запрос. Честно-честно.

Это понятно, просто то, что вы написали, это даже не SQL. Там под капотом может быть что угодно, какая-нибудь noSQL облачная даза банных, например. Т.е. еще сто лет назад большинству погроммистов уже не нужно было знать в деталях SQL, достаточно всяких ODBC или там OLE DB. Хотя и слова-то это с трудом вспоминаются. Или вообще мышкой повозить в Дельфи и всего делов. Но тогда еще были нужны ДВА. А сейчас-то?

А кому нужны DBA - так любой конторе с Ораклом Oracle DBA это 5 колонна Оракла в вашем датацентре.

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

[Aleksey Kudinov]

Всё это замечательно, конечно, но ведь каждый несёт резюме с laundry list of databases. Оракль? Да не вопрос - у нас это корп стандарт. Процентов 90 сразу предупреждают "ну до использования PL/SQL мы не дошли" - не проблема, обойдёмся без написания pipeline functions. И после всех этих танцев с бубнами, не могут повязать три простенькие таблички.

[Likenew]

Всё это замечательно, конечно, но ведь каждый несёт резюме с лаундры лист оф датабасес. Оракль? Да не вопрос - у нас это корп стандарт. Процентов 90 сразу предупреждают "ну до использования ПЛ/СЪЛ мы не дошли" - не проблема, обойдёмся без написания пипелине фунцтионс. И после всех этих танцев с бубнами, не могут повязать три простенькие таблички.

Тут много может быть причин, может у вас такие деньги платят, что многие считают, что достаточно упомянуть СЪЛ. Или, они же в < JBDC> пишут орацловский дривер или ишо какой-нить из вашего списка, И считают, что они работают с Орацле. Я вот натуральный ДБ девелопер с сертификатом от Орацле, не могу найти работу, бо в списке заявленых муст хаве скиллс скока всего понаписано, что просто нереально все ето знать и, главное, использовать в одном месте. Вы же хотите, чтобы вам на < java> все деревья переломали самым оптимальным образом, И в добавок на етом же уровне в СЪЛ все хинты перечислили. Я вот на проекте работала, улучшала структуру базы типа, надо было старую базу подогнать под то, что ОРМ выдало для обеспечения новых функций, так в завершение всего, на етапе отладки, когда уже все сваливали кучу, оказалось , что некоторые запросы типа найти, зарегистрирован ли уже етот пациент, выполнялись по 30 минут, я не шучу. Вот мне И пришлось <tune> все ето добро, по-простому просто переписать, переструктурировать все запросы. Я уж промолчу про саму модель данных < >.

Мне каецца, что с увеличением мощности кмпьютеров, ето < fine tuning SQL> заодно со знанием самого СЪЛ уже никому не нужно. Посмотрите сколько софта появилось, который по-быстрому преобразует текстовые файлы в табличные И наоборот. Отсюда И надвигающаяся непопулярность дорогих ДБ. Выбрали всех людей из департмента=7, как Аццко Мото писал, в датасет, а потом потихоньку на < java> выбираем, что нужно, И все довольны < >. Вот где хадооп с амазоном со своими сервисами стал процветать. Все хранится в текстовых файлах, главное алгоритмы знать, как с ними работать. Да И появление <noSQL> баз расслабило народ, вон то же ПИГ обрабатывает запросы без <SQL>. Я вот тоже лыжи вострю на <Python>, там на <Spark> дальше, надеясь, что мне знание <SQL> поможет писать ленивые скрипты на <Spark>, используя <SQL/ HQL>, а не <SparkSQL>, хотя там тоже не много надо знать

[fruit6]

Это хорошо что рынок анализируете и изучаете. Так и работу найдете современную.

[Likenew]

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

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

[major Major Major Major]

Это понятно, просто то, что вы написали, это даже не SQL. Там под капотом может быть что угодно, какая-нибудь noSQL облачная даза банных, например. Т.е. еще сто лет назад большинству погроммистов уже не нужно было знать в деталях SQL, достаточно всяких ODBC или там OLE DB.

Так и я про это. Человек использует Linq для доступа к MS SQL или Mongo, не понимая как оно работает унутри, но в резюме-то у него гордо стоит знание конкретного сервеа.
Для доступа через OLE DB таки надо знать как писать запросы - а вот для ORM & LINQ все уже на другом уровне и при попытке поспрошать про SQL народ конкретно плывет - ибо если им понадобиться сделать допустим HAVING (классика) они вероятно напишут что то вроде

foreach (var department in context.Departments)
{
if (department.Peoples.Count() > 10)
{
///
}
}

даже если чел что то соображает и напишет

foreach (department in context.Departments.Where(d => .Peoples.Count() > 10))
{
//
}

знать как это транслируется в конкретный запрос он не будет. То есть знания языка запросов будь то ansi sql, монговский js или что там еще у него отсутсвуют в принципе. Об этои TC и спрашивал

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

Тем у кого он уже есть

[Sergunka]

И главное обилие данных которые не требуют транзакционных баз и могут быть легко потеряны быз глобальных проблем логи/клики/блоги/etc.

+100

Это 99% проектов сейчас в корпе.

[Вячеслав Викторович]

SQL zапрос не должен длитъся больше 100 мс. НУ и т.д.
Для высоконагруженных систем говнокодерство - смертъ системе.

[Likenew]

Так и я про это. Человек использует Линъ для доступа к МС СЪЛ или Монго, не понимая как оно работает унутри, но в резюме-то у него гордо стоит знание конкретного сервера.

Ну так народ на другой сторне барикад перечисляет же все тоолс, которые используются только администратором того же хадоопа
или мной, когда мне надо <setup> все ето добро на попробовать дома. Я вот когда читала обьявления о работе, приходила в ужос < : horror: > как все ето можно знать. а тут пораозбравшись немнога

[Вячеслав Викторович]

Так и я про это. Человек использует Линъ для доступа к МС СЪЛ или Монго, не понимая как оно работает унутри, но в резюме-то у него гордо стоит знание конкретного сервера.

Ну так народ на другой сторне барикад перечисляет же все тоолс, которые используются только администратором того же хадоопа
или мной, когда мне надо <setup> все ето добро на попробовать дома. Я вот когда читала обьявления о работе, приходила в ужос < : horror: > как все ето можно знать. а тут пораозбравшись немнога

У вас чего-нибудь хотъ работает или ни хера?
Если ни хера не работает, то значит полный капут. Вы выходит нихера не умеете.
Отсюда и вытекает полная диффомация полной пертуберрации.

[Aleksey Kudinov]

Так и я про это. Человек использует Линъ для доступа к МС СЪЛ или Монго, не понимая как оно работает унутри, но в резюме-то у него гордо стоит знание конкретного сервера.

Ну так народ на другой сторне барикад перечисляет же все тоолс, которые используются только администратором того же хадоопа
или мной, когда мне надо <setup> все ето добро на попробовать дома. Я вот когда читала обьявления о работе, приходила в ужос < : horror: > как все ето можно знать. а тут пораозбравшись немнога

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

А первый вопрос - оторвать и выкинуть - почти что dept=7:

Users: {Id, Name} [{1,A}, {2,B}, {3,C}]
User_Attrs: {Id, Name}, [{1, IsAdmin}]
User_Attr_Values: {UserId, AttrId, Value}, [{1,1,1}, {2,1,0}]

Написать сиквел для:
User_Roles {UserName, Role}, [{A, admin}, {B, user}, {C, user}]

[АццкоМото]

Так и я про это. Человек использует Linq для доступа к MS SQL или Mongo, не понимая как оно работает унутри, но в резюме-то у него гордо стоит знание конкретного сервеа.
Для доступа через OLE DB таки надо знать как писать запросы - а вот для ORM & LINQ все уже на другом уровне и при попытке поспрошать про SQL народ конкретно плывет - ибо если им понадобиться сделать допустим HAVING (классика) они вероятно напишут что то вроде

foreach (var department in context.Departments)
{
if (department.Peoples.Count() > 10)
{
///
}
}

даже если чел что то соображает и напишет

foreach (department in context.Departments.Where(d => .Peoples.Count() > 10))
{
//
}

знать как это транслируется в конкретный запрос он не будет. То есть знания языка запросов будь то ansi sql, монговский js или что там еще у него отсутсвуют в принципе. Об этои TC и спрашивал

Все-таки мы немного о разном. Фишка в том, что если погромист знает SQL как отче наш, он все равно не узнает, какой запрос будет сгенерен. И даже не узнает, будет ли разница между первым и вторым вариантом, что вы привели. Ну, пока ему не придется заглянуть под капот, что далеко не факт. Хуже того, если он выяснит, что в результате получается SELECT ... WHERE COUNT > 10, что дает это знание? Да ничего. Условно говоря, в зависимости от правильности настройки индексов это может быть либо идеально, либо плохо, либо пох, потому что записей там больше 10 не бывает SQL как язык - прост, как барабан, его не стыдно забыть и вспомнить, если понадобится. А вот всяких нюансов с оптимизацией и администрированием - вагон. Если у них влезть по колено, то ты уже не погромист, а исчезающий мамонт-дибиэй. Кому это нужно? Из современных погромистов - мало кому и это правильно.

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

Тем у кого он уже есть

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

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

[Easbayguy]

Oracle/SQL стал жертвой двух обстоятельств: Жадности Лэрри не опускавшего вниз стоимости лицензий и огромного количества тупых дбэев, не будем показывать пальцами.

[Likenew]

Так и я про это. Человек использует Линъ для доступа к МС СЪЛ или Монго, не понимая как оно работает унутри, но в резюме-то у него гордо стоит знание конкретного сервера.

Ну так народ на другой сторне барикад перечисляет же все тоолс, которые используются только администратором того же хадоопа
или мной, когда мне надо <setup> все ето добро на попробовать дома. Я вот когда читала обьявления о работе, приходила в ужос < : horror: > как все ето можно знать. а тут пораозбравшись немнога

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

А первый вопрос - оторвать и выкинуть - почти что депт=7:

Усерс: {Ид, Наме} [{1,A}, {2,B}, {3,C}]
УсерАттрс: {Ид, Наме}, [{1, IsAdmin}]
УсерАттрВалуес: {УсерИд, АттрИд, Валуе}, [{1,1,1}, {2,1,0}]

Написать сиквел для:
УсерРолес {УсерНаме, Роле}, [{A, admin}, {B, user}, {Ц, усер}]

Ну так вы же коряво задачу ставите, ни тебе табленаме, ни тебе структуры самой таблицы,ни тебе нормальным цолумн намес, чтобы таблицы связать, никак не можете сами ето выразить правильными словами, вот народ И теряется на интервиеш.
< with users as
( select t1.Id,t1.name, decode(t2.name, 'isadmin', 'admin','user') attr from
users t1 left outer join userattrc t2 on ( t1.id = t2.id))
select users.name, nvl(t3.value,"no_role",users.attr) role
from users left outer join userattrvalues t3 on ( users.id = t3.userid) >
тогда у вас получится :< [{A, admin}, {B, user}, {Ц, но роле}]> бо ваша последняя таблица не содержит значения для третьего участника. И вам никто такого не скажет на интервиеш, но подумает много раз
поправилась

[Aleksey Kudinov]

Так и я про это. Человек использует Линъ для доступа к МС СЪЛ или Монго, не понимая как оно работает унутри, но в резюме-то у него гордо стоит знание конкретного сервера.

Ну так народ на другой сторне барикад перечисляет же все тоолс, которые используются только администратором того же хадоопа
или мной, когда мне надо <setup> все ето добро на попробовать дома. Я вот когда читала обьявления о работе, приходила в ужос < : horror: > как все ето можно знать. а тут пораозбравшись немнога

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

А первый вопрос - оторвать и выкинуть - почти что депт=7:

Усерс: {Ид, Наме} [{1,A}, {2,B}, {3,C}]
УсерАттрс: {Ид, Наме}, [{1, IsAdmin}]
УсерАттрВалуес: {УсерИд, АттрИд, Валуе}, [{1,1,1}, {2,1,0}]

Написать сиквел для:
УсерРолес {УсерНаме, Роле}, [{A, admin}, {B, user}, {Ц, усер}]

Ну так вы же коряво задачу ставите, ни тебе табленаме, ни тебе структуры самой таблицы,ни тебе нормальным цолумн намес, чтобы таблицы связать, никак не можете сами ето выразить правильными словами, вот народ И теряется на интервиеш.
< with users as
( select t1.Id,t1.name, decode(t2.name, 'isadmin', 'admin','user') attr from
users t1 left outer join userattrc t2 on ( t1.id = t2.id))
select users.name, nvl(t3.value,"no_role",users.attr) role
from users left outer join userattrvalues t3 on ( users.id = t3.userid) >
тогда у вас получится :< [{A, admin}, {B, user}, {Ц, но роле}]> бо ваша последняя таблица не содержит значения для третьего участника. И вам никто такого не скажет на интервиеш, но подумает много раз
поправилась

То есть прочитать внимательно прежде чем как наезжать не случилось...
На интервью всё нормально, расписано на whiteboard, просто shorthand on the forum. Users, UserAttrs and UserAttrValues и есть табленаме и структура там же - в первых {}. Также оговаривается, что роль по умолчанию - user.

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