На мой взгляд, есть три «трека» с навыками работы с базами данных: Developer, DBA и Architect. С точки зрения разработки вы хотите сосредоточиться на разработке, понимать архитектуру и подбирать столько DBA, сколько вам нужно.
Как разработчик, ключевым моментом (на мой взгляд) было бы привести ваш SQL к действительно хорошему стандарту. Как интервьюер, если я ищу разработчика, мне все равно, можете ли вы разрабатывать базы данных так же, как вы можете писать запросы. Предполагая, что вы знаете о своих основных командах CRUD, вы знаете о:
Хранимые процедуры (не только как их использовать, но и когда и почему)
Представления (то же самое, включая материализованные представления)
Триггеры (вставка, обновление, удаление, как и почему)
Курсоры (особенно влияние на производительность)
Ссылочная целостность
Сделки
Индексы
Добавление значений по умолчанию, ограничений и идентификаторов в таблицы
Комплексное использование групповой и имеющей
Функции особенно:
- манипуляции с датой и временем
- Струнные манипуляции
- Обработка нулей
Вы должны иметь возможность извлекать любые данные, которые вам нужны, из вашей базы данных, используя только SQL, вам никогда не нужно манипулировать или анализировать их каким-либо образом, используя ваш процедурный код (вы можете выбрать, но это будет выбор, а не вы не знал, как это сделать с SQL).
Как разработчик, я хотел бы взглянуть на заявку SQL для умничков Джо Селко. Много SQL для того, чтобы делать то, о чем вы, возможно, даже и не думали, что можете делать в SQL.
Один из лучших способов научиться этому - утомительно, как кажется, написание отчетов (управленческая информация). Я видел, как многие люди жалуются на то, что написание отчетов утомительно, а потом делают это действительно, очень плохо (и не только потому, что они не пытались). Отчеты, как правило, близки к чистому SQL, поэтому вам нужно по-настоящему ознакомиться с имеющимися инструментами, а сложный отчет действительно разоблачает тех, кто знает SQL, от тех, кто этого не знает. Люди, как правило, не хотят ждать слишком долго, поэтому производительность также является ключевым фактором.
Посмотрите на свою текущую базу данных и найдите кучу действительно очень неловких вещей, которые кто-то может захотеть узнать. Подумайте о маркетинге, тенденциях, наиболее и наименее популярных. Затем попробуйте объединить их в один запрос.
С точки зрения производительности, я бы также попытался понять, как работает оптимизатор запросов, как он принимает решение о том, когда использовать индекс и когда сканировать таблицы, когда индексы помогут и когда они будут мешать.
Хороший разработчик не просто пишет хорошие запросы, они пишут быстрые, поддерживаемые запросы. Чтобы действительно справиться с этим, вам нужно поиграть с базой данных с дюжиной (или более таблиц), содержащей, в идеале, миллионы строк. Именно тогда вы начинаете видеть запросы, которые, как вам показалось, прекрасно потянули за пятки.
Материал для архитекторов / дизайнеров, который другие хорошо освещали. Все, что я хотел бы сказать по этому вопросу, - это то, что для каждой базы данных, которая должна быть разработана, для нее необходимо написать сотни запросов. Возможно, вы захотите учесть это пропорциональное распределение работы при повышении квалификации и убедиться, что ваши запросы действительно на пустом месте.
С точки зрения ссылок это зависит от платформы - все эти вещи, как правило, зависят от платформы. Но тогда для этого и нужен Google.
Не совсем подозреваю, что вы хотите, но стоит знать, так как многие люди, которые думают, что знают SQL, на самом деле не знают ...