к такой хуйне вегда приписка "в день" Пресс за 8 минут ( в день ) итд.
13.03.2019, 18:57
когда 3 дня подряд делал по 15 минут на пресс
Да и SQL вполне можно разобрать если действительно 10 минут в день уделять... гдето за год, если уже шаришь хоть сколько то, за два думаю точно.
Второй вариант в этом случае смотрится правдоподобно. Проще придумать, чего нельзя выучить за 24 часа в день
теорию реляционных БД
особенности различых СУБД и их влияние на процесс семантического моделирования с использованием методологии дальнейшей нормализации, контролируемой избыточности и т.д.
правила и особенности формирования индексов для различных задач,
использование ограничений целостности данных при моделировании.
конструкции языка, ddl, dml, для целевых СУБД
вспомогательные конструкции типа хинтов
разновидности хранимых процедур, триггеров и т.д.
аналитический функционал и методологию выявления узких мест БД и способы их решения.
взаимодействие гетерогенных систем
особенности проектирования распределенных систем
и т.д. и т.п...овердохуя
конечно, можно наплевать а все..и получить очередную хуиту...наебенив километровый запрос с левым внешним соединением по 30-40 отношениям или с декартовым произведением...и искренне удивляться, почему сервер так долго выборку делает
особенности различых СУБД и их влияние на процесс семантического моделирования с использованием методологии дальнейшей нормализации, контролируемой избыточности и т.д.
правила и особенности формирования индексов для различных задач,
использование ограничений целостности данных при моделировании.
конструкции языка, ddl, dml, для целевых СУБД
вспомогательные конструкции типа хинтов
разновидности хранимых процедур, триггеров и т.д.
аналитический функционал и методологию выявления узких мест БД и способы их решения.
взаимодействие гетерогенных систем
особенности проектирования распределенных систем
и т.д. и т.п...овердохуя
конечно, можно наплевать а все..и получить очередную хуиту...наебенив километровый запрос с левым внешним соединением по 30-40 отношениям или с декартовым произведением...и искренне удивляться, почему сервер так долго выборку делает
Ну хз:
1)По индексам особо учить ничего не нужно, просто, знать что это такое и когда использовать, а потом в один прекрасный момент, когда они фактически понадобятся вспомнить про них и опять же почитать рекомендации.
2)По нормализации тоже все изи. Просто изучить какой-нибудь IDEF1x и проектировать базу, как там написано и на выходе получаешь 3-ю нормальную форму, которой достаточно.
3)хинты- опять же, помнить, что они есть и при фактических проблемах погуглить про них.
и т д.
Имхо, основное, что нужно знать- это как составить запрос и операторы, а все остальное вторично и можно ознакомится по мере необходимости.
Я несколько лет работаю в MS SQL и живу без знания хинтов, лишь при каких-то проблемах изучаю возможности их применения.
1)По индексам особо учить ничего не нужно, просто, знать что это такое и когда использовать, а потом в один прекрасный момент, когда они фактически понадобятся вспомнить про них и опять же почитать рекомендации.
2)По нормализации тоже все изи. Просто изучить какой-нибудь IDEF1x и проектировать базу, как там написано и на выходе получаешь 3-ю нормальную форму, которой достаточно.
3)хинты- опять же, помнить, что они есть и при фактических проблемах погуглить про них.
и т д.
Имхо, основное, что нужно знать- это как составить запрос и операторы, а все остальное вторично и можно ознакомится по мере необходимости.
Я несколько лет работаю в MS SQL и живу без знания хинтов, лишь при каких-то проблемах изучаю возможности их применения.
вот вот...
1. "особо учить ничего не нужно.." ну вот я и смотрю, как народ хуячит вот это вот все (в том числе и в пром БД) без понимания их устройства и влияния на "dml операции - мутаторы". ой блять, что то медленно, а давай ка въебеним индекс (по каждому суррогатному атрибуту отдельно или как Бг на душу положит). Что такое, например, B-Tree (наиболее часто используемая модель построения индекса) и как она работает, как правильно сформировать (предварительно проанализировав структуру данных) атрибутивную последовательность, как правильно распределить сегментирование и рост относительно анализа пиковой и номинальной нагрузки - нахуй. это же индекс.
а потом, ой, бля.. чета на инсёртах база в блокировки входит, или на обновлении (не дай Боже на каскадном). А сука, индексы потому что в большинстве своем нахуй не вперлись в таком количестве и качестве. База растет, индексы больше самой таблицы и организованы в бардак.
Дада... мелкософтовская практика суррогатных первичных ключей рулит давно и бестолково.
"когда они фактически понадобятся вспомнить про них" - поздравляю. Нахуй столько трудов ученые и разрабы писали - не понятно, ведь, особо ничего не нужно учить.
Рекомендую Д.Кнут т.3 Искусство программирования. Сортировка и поиск.
Это база.
Уверяю, ты оч по другому взглянешь на многие вещи.
2. Видал я эту "нормализацию" после "изучить какой-нибудь" и сделать декомпозицию.. ну ну... такие перлы выдают, что ни боже мой. Хуячат по шаблону, без анализа задачи, целевой платформы, прогнозируемой нагрузки (ее вообще кто-нибудь делал?) и т.д. и т.п. Это пиздец. На выходе такое говнище получается. Справочники говна. Таблицы фактов без фактов, кортежи дубликаты, null где нужно и не нужно, неебических степеней отношения и проч. В итоге - запросы с артефактами и БД уже не БД, т.к. содержит противоречивые состояния.
3 Хинты, аналитика статистики и прочие штуки это уже дополнение, позволяющее разработчику получить данные для детального мониторинга и поддерживания прогнозируемого быстродействия.
Составить запрос так, чтобы он был эффективным и не вешал систему нужно знать и уметь:
- знать семантическую структуру БД
- возможные интеграционные узкие места (данные получаются из других систем)
- уметь строить и читать планы запросов
- знать методологию обратной композиции (или ты думаешь, что порядок соединений не важен?)
- знать, языковые конструкции, которые помогут сделать запрос более эффективным
- понимать, как статистика БД будет влиять на запрос
- чем, например будет отличаться hash соединение от nested loop для малых и больших объемов данных и что выбрать в каком случае
и т.д. и т.п.
Фишка в том, что Все то, о чем ты говоришь "когда понадобится" - происходит всегда сразу.
Это всегда - комплекс проблем, которые каскадно наваливаются одна на другую.
Без понимания этих процессов ты оч быстро навернешь БД, с большой долей вероятности безвозвратной потери данных. Если ты думаешь, что это "задача админа" - ошибаешься. Админы как правило ни в зуб ногой по вн структуре. Могут мониторить только базовые показатели жизнедеятельности, но не вн структуру и ту хуиту, которую там нагородили (и все взаимосвязи).
а вообще - все приходит с опытом.
1. "особо учить ничего не нужно.." ну вот я и смотрю, как народ хуячит вот это вот все (в том числе и в пром БД) без понимания их устройства и влияния на "dml операции - мутаторы". ой блять, что то медленно, а давай ка въебеним индекс (по каждому суррогатному атрибуту отдельно или как Бг на душу положит). Что такое, например, B-Tree (наиболее часто используемая модель построения индекса) и как она работает, как правильно сформировать (предварительно проанализировав структуру данных) атрибутивную последовательность, как правильно распределить сегментирование и рост относительно анализа пиковой и номинальной нагрузки - нахуй. это же индекс.
а потом, ой, бля.. чета на инсёртах база в блокировки входит, или на обновлении (не дай Боже на каскадном). А сука, индексы потому что в большинстве своем нахуй не вперлись в таком количестве и качестве. База растет, индексы больше самой таблицы и организованы в бардак.
Дада... мелкософтовская практика суррогатных первичных ключей рулит давно и бестолково.
"когда они фактически понадобятся вспомнить про них" - поздравляю. Нахуй столько трудов ученые и разрабы писали - не понятно, ведь, особо ничего не нужно учить.
Рекомендую Д.Кнут т.3 Искусство программирования. Сортировка и поиск.
Это база.
Уверяю, ты оч по другому взглянешь на многие вещи.
2. Видал я эту "нормализацию" после "изучить какой-нибудь" и сделать декомпозицию.. ну ну... такие перлы выдают, что ни боже мой. Хуячат по шаблону, без анализа задачи, целевой платформы, прогнозируемой нагрузки (ее вообще кто-нибудь делал?) и т.д. и т.п. Это пиздец. На выходе такое говнище получается. Справочники говна. Таблицы фактов без фактов, кортежи дубликаты, null где нужно и не нужно, неебических степеней отношения и проч. В итоге - запросы с артефактами и БД уже не БД, т.к. содержит противоречивые состояния.
3 Хинты, аналитика статистики и прочие штуки это уже дополнение, позволяющее разработчику получить данные для детального мониторинга и поддерживания прогнозируемого быстродействия.
Составить запрос так, чтобы он был эффективным и не вешал систему нужно знать и уметь:
- знать семантическую структуру БД
- возможные интеграционные узкие места (данные получаются из других систем)
- уметь строить и читать планы запросов
- знать методологию обратной композиции (или ты думаешь, что порядок соединений не важен?)
- знать, языковые конструкции, которые помогут сделать запрос более эффективным
- понимать, как статистика БД будет влиять на запрос
- чем, например будет отличаться hash соединение от nested loop для малых и больших объемов данных и что выбрать в каком случае
и т.д. и т.п.
Фишка в том, что Все то, о чем ты говоришь "когда понадобится" - происходит всегда сразу.
Это всегда - комплекс проблем, которые каскадно наваливаются одна на другую.
Без понимания этих процессов ты оч быстро навернешь БД, с большой долей вероятности безвозвратной потери данных. Если ты думаешь, что это "задача админа" - ошибаешься. Админы как правило ни в зуб ногой по вн структуре. Могут мониторить только базовые показатели жизнедеятельности, но не вн структуру и ту хуиту, которую там нагородили (и все взаимосвязи).
а вообще - все приходит с опытом.
Ну хз, в колледже только селектор научили делать, а когда устроился на работу , то решал проблемы имеющихся баз, где и набил руку. Т.е если есть система наставничества,
Или нормальный коллектив, то можно все на ходу доучивать.На собеседованиях кстати обычно просят запрос составить на листочке.
Или нормальный коллектив, то можно все на ходу доучивать.На собеседованиях кстати обычно просят запрос составить на листочке.
Дальше должна быть книга "Как за 60 секунд понять, что вы уже знаете SQL".
Не, ну так то достаточно написать SELECT1 и ты уже программист баз данных. Это уже потом этот SELECT 1 вырастает в запрос на пару десятков ато и сотен строк, но всё тот же SELECT. И в SQL важнее понять саму логику построения запросов, а не его синтаксис. Знавал я спецов знающих особо специфические операторы, но не умеющие построить работающий запрос хоть ими хоть простыми средствами.
Кораптор от it.
Описанное уже наступило, встречайте 19-летних тим лидов:
https://dou.ua/lenta/interviews/19-years-old-team-lead/
Описанное уже наступило, встречайте 19-летних тим лидов:
https://dou.ua/lenta/interviews/19-years-old-team-lead/
https://dou.ua/lenta/interviews/17-years-old-architect/
у них это семейное что ли? вот про её сестру
у них это семейное что ли? вот про её сестру
Чтобы написать коммент, необходимо залогиниться
