Еще на тему
Не хорошо и не ужасно
Популярные geek
 | it-юморРейтинг: 97,966.0 |
 | программированиеРейтинг: 16,317.7 |
 | geek pornРейтинг: 2,854.0 |
 | матанРейтинг: 2,576.4 |
 | Приколы для математиковРейтинг: 1,742.0 |
Сейчас на сайте
Всего пользователей на сайте: 809
...
хотя с такой логикой можно и что-то и выучить по 10 минут в день, если не тупой
Тупо изучаешь операторы и все, так как SQL элементарный язык. Вот если T-SQL хочешь, то тут малость по труднее, но если ты знаком с любым ЯП, то изи изучается.
http://dcms-fiera.ru/wapmaster/sql_teach/
особенности различых СУБД и их влияние на процесс семантического моделирования с использованием методологии дальнейшей нормализации, контролируемой избыточности и т.д.
правила и особенности формирования индексов для различных задач,
использование ограничений целостности данных при моделировании.
конструкции языка, ddl, dml, для целевых СУБД
вспомогательные конструкции типа хинтов
разновидности хранимых процедур, триггеров и т.д.
аналитический функционал и методологию выявления узких мест БД и способы их решения.
взаимодействие гетерогенных систем
особенности проектирования распределенных систем
и т.д. и т.п...овердохуя
конечно, можно наплевать а все..и получить очередную хуиту...наебенив километровый запрос с левым внешним соединением по 30-40 отношениям или с декартовым произведением...и искренне удивляться, почему сервер так долго выборку делает
1)По индексам особо учить ничего не нужно, просто, знать что это такое и когда использовать, а потом в один прекрасный момент, когда они фактически понадобятся вспомнить про них и опять же почитать рекомендации.
2)По нормализации тоже все изи. Просто изучить какой-нибудь IDEF1x и проектировать базу, как там написано и на выходе получаешь 3-ю нормальную форму, которой достаточно.
3)хинты- опять же, помнить, что они есть и при фактических проблемах погуглить про них.
и т д.
Имхо, основное, что нужно знать- это как составить запрос и операторы, а все остальное вторично и можно ознакомится по мере необходимости.
Я несколько лет работаю в MS SQL и живу без знания хинтов, лишь при каких-то проблемах изучаю возможности их применения.
1. "особо учить ничего не нужно.." ну вот я и смотрю, как народ хуячит вот это вот все (в том числе и в пром БД) без понимания их устройства и влияния на "dml операции - мутаторы". ой блять, что то медленно, а давай ка въебеним индекс (по каждому суррогатному атрибуту отдельно или как Бг на душу положит). Что такое, например, B-Tree (наиболее часто используемая модель построения индекса) и как она работает, как правильно сформировать (предварительно проанализировав структуру данных) атрибутивную последовательность, как правильно распределить сегментирование и рост относительно анализа пиковой и номинальной нагрузки - нахуй. это же индекс.
а потом, ой, бля.. чета на инсёртах база в блокировки входит, или на обновлении (не дай Боже на каскадном). А сука, индексы потому что в большинстве своем нахуй не вперлись в таком количестве и качестве. База растет, индексы больше самой таблицы и организованы в бардак.
Дада... мелкософтовская практика суррогатных первичных ключей рулит давно и бестолково.
"когда они фактически понадобятся вспомнить про них" - поздравляю. Нахуй столько трудов ученые и разрабы писали - не понятно, ведь, особо ничего не нужно учить.
Рекомендую Д.Кнут т.3 Искусство программирования. Сортировка и поиск.
Это база.
Уверяю, ты оч по другому взглянешь на многие вещи.
2. Видал я эту "нормализацию" после "изучить какой-нибудь" и сделать декомпозицию.. ну ну... такие перлы выдают, что ни боже мой. Хуячат по шаблону, без анализа задачи, целевой платформы, прогнозируемой нагрузки (ее вообще кто-нибудь делал?) и т.д. и т.п. Это пиздец. На выходе такое говнище получается. Справочники говна. Таблицы фактов без фактов, кортежи дубликаты, null где нужно и не нужно, неебических степеней отношения и проч. В итоге - запросы с артефактами и БД уже не БД, т.к. содержит противоречивые состояния.
3 Хинты, аналитика статистики и прочие штуки это уже дополнение, позволяющее разработчику получить данные для детального мониторинга и поддерживания прогнозируемого быстродействия.
Составить запрос так, чтобы он был эффективным и не вешал систему нужно знать и уметь:
- знать семантическую структуру БД
- возможные интеграционные узкие места (данные получаются из других систем)
- уметь строить и читать планы запросов
- знать методологию обратной композиции (или ты думаешь, что порядок соединений не важен?)
- знать, языковые конструкции, которые помогут сделать запрос более эффективным
- понимать, как статистика БД будет влиять на запрос
- чем, например будет отличаться hash соединение от nested loop для малых и больших объемов данных и что выбрать в каком случае
и т.д. и т.п.
Фишка в том, что Все то, о чем ты говоришь "когда понадобится" - происходит всегда сразу.
Это всегда - комплекс проблем, которые каскадно наваливаются одна на другую.
Без понимания этих процессов ты оч быстро навернешь БД, с большой долей вероятности безвозвратной потери данных. Если ты думаешь, что это "задача админа" - ошибаешься. Админы как правило ни в зуб ногой по вн структуре. Могут мониторить только базовые показатели жизнедеятельности, но не вн структуру и ту хуиту, которую там нагородили (и все взаимосвязи).
а вообще - все приходит с опытом.
Или нормальный коллектив, то можно все на ходу доучивать.На собеседованиях кстати обычно просят запрос составить на листочке.
Очень похоже на типов, любящих совать union везде, где только можно.
Описанное уже наступило, встречайте 19-летних тим лидов:
https://dou.ua/lenta/interviews/19-years-old-team-lead/
у них это семейное что ли? вот про её сестру