То, что существенные dba навыки являются разработчиком, должно учиться?
6 ответов
Возможности хранения и оптимизации базы данных огромны. Знание того, как правильно индексировать и разделять таблицы, - бесценное знание.
Кроме того, как читать план выполнения запроса. SQL - такой классный язык, что он точно сообщит вам, как он будет выполнять ваш код, если вы вежливо спросите. Это абсолютно необходимо для оптимизации вашего кода и поиска узких мест.
Обслуживание базы данных (резервное копирование, сжатие файлов и т. Д.) Всегда важно для бесперебойной работы вашего сервера. Это то, что тоже часто упускают из виду.
Разработчики должны знать все о триггерах и хранимых процедурах - чтобы база данных работала на вас. Эти вещи могут помочь автоматизировать так много задач, и часто разработчики не обращают на них внимания и пытаются справиться со всем этим на стороне приложения. когда с ними действительно должно работать нечто, мыслящее наборами.
Это подводит меня к самому важному моменту, разработчикам баз данных необходимо мыслить наборами. Часто я слышу: «Для каждой строки я хочу ...», и это обычно тревога в моей голове. Вы должны думать о том, как набор взаимодействует и какие действия вы хотите предпринять для целых столбцов.
Разработчик несет ответственность за все, что делает его код a) правильным и b) быстрым.
Это, конечно же, включает создание индексов и таблицы.
Делать администратором баз данных ответственным за индексы - плохая идея. Что делать, если код работает медленно? Кто виноват: разработчик с плохим кодом или DBA с плохим индексом?
DBA должен передавать операции поддержки базы данных, такие как создание резервных копий, создание инфраструктуры и т. Д., и сообщать о нехватке ресурсов.
Он или она не должны быть единственным лицом для принятия решений, влияющих на производительность всей системы баз данных.
Реляционные базы данных, на данный момент, еще не в том состоянии, которое позволило бы разделить ответственность, чтобы разработчики могли делать запросы правильными , а администратор баз данных мог бы сделать их быстрыми . Это миф.
Если есть нехватка ресурсов (например, индекс делает некоторые запросы быстрыми за счет медленных операций DML ), об этом следует сообщить администратором баз данных, а не исправлено .
Теперь настало время принять решение. Что нам еще нужно, быстрый запрос или быстрая вставка?
Это решение должен принять менеджер программы (а не администратор баз данных или разработчик).
И когда решение будет принято, перед разработчиком должна быть поставлена новая задача: «сделать запрос SELECT максимально быстрым, учитывая, что вы этого не делаете»
Оптимизация. Ваш код всегда должен использовать как можно меньше ресурсов.
Я бы порекомендовал разобраться в архитектуре безопасности соответствующей СУБД.
Это может облегчить вашу разработку безопасного кода.
Имея в виду SQL Server, например:
- Поймите, почему вашему «управляемому коду» (например, .NET CLR) не следует предоставлять повышенные привилегии. Каковы будут последствия этого?
- Что такое цепочка владения между базами данных? Как это работает?
- Понять контекст выполнения.
- Как работает собственное шифрование SQL Server?
- Как вы можете подписать хранимую процедуру? Зачем вам вообще это нужно?
- И т.д.
Как правило, чем больше вы понимаете о движке, с которым работаете, тем большую производительность вы можете получить от него.
Одна вещь, которая сейчас приходит в голову, - это то, как ориентироваться и понимать информацию, которую вам предоставляют "системные" таблицы / представления базы данных. Например, на сервере sql представления, которые находятся в базе данных master. Эти представления содержат такую информацию, как текущие входы в систему, списки таблиц и разделов и т. Д., Которая полезна при попытке отследить такие вещи, как зависание входа в систему, подключение пользователей в настоящее время и т. Д.
Relationships of your tables. You should always have a recent printout and soft copy of your database. You need to know the primary keys, foreign keys, required and auto filled columns, without that I think you can't write efficient queries or make sure your database is carrying only what it needs.
I think everyone else covered it.