Как опытный специалист по SQL Server, я наблюдал различные техники настройки и разработки на протяжении своей 18-летней карьеры. Когда дело доходит до подхода к проекту, существуют два основных принципа: Code First и Database First. В то время как некоторые могут аргументировать в пользу Code First, я твердо верю, что правильным подходом является Database First.
С Database First процесс разработки начинается с бизнес-аналитика, который собирает требования и создает ERD базы данных. Только после этого начинается фаза кодирования. Такой подход гарантирует, что структура базы данных хорошо спроектирована и соответствует потребностям проекта.
Одним из полезных инструментов для развертывания DDL (Data Definition Language) являются миграции. Миграции позволяют проектировать таблицы любым желаемым способом, устраняя необходимость в отдельных DDL-скриптах. Примером инструмента, который облегчает этот процесс, является FluentMigrator.
Недавно я столкнулся с интересной ситуацией, связанной с проектом .NET MVC, работающим на SQL Server 2016. В базе данных были таблицы многие-ко-многим для клиентов, адресов и номеров телефонов. Однако, способ, которым эти таблицы были связаны с клиентом, был довольно загадочным.
Вместо использования простого оператора JOIN для получения списка адресов или номеров телефонов для клиента, разработчик создал пользовательский тип таблицы и две хранимые процедуры. Этот подход, хотя и нестандартный, стремился уменьшить затраты на обслуживание в будущем при добавлении дополнительных столбцов.
Важно быть открытым к различным подходам и учиться на них, но необходимо учитывать преимущества и недостатки каждого метода. Давайте сравним два метода получения списка адресов.
Существующий код в производстве, который использовал пользовательский тип таблицы и хранимые процедуры, привел к плану запроса с общей стоимостью 0.0312159. С другой стороны, более традиционный подход с использованием операторов JOIN дал план запроса с стоимостью 0.0065704.
Очевидно, что код в производстве вызывал более высокие затраты и потреблял больше ресурсов. Когда оба процедуры были запущены вместе, запрос с использованием JOIN составлял всего 17% от общей партии. Это подчеркивает важность написания эффективного SQL-кода и учета его производительности.
SQL часто недооценивается как простой язык, и некоторые разработчики считают его менее сложным по сравнению с объектно-ориентированными языками. Однако SQL предлагает мощные возможности, которые могут значительно повлиять на производительность. Важно избегать мышления “просто добавьте больше оборудования” и вместо этого сосредоточиться на оптимизации запросов и проектировании базы данных.
Чтобы предотвратить проблемы, подобные описанной выше, я рекомендую внедрить надежный процесс проверки кода для всего приложения и кода базы данных, независимо от стажа разработчика. Проверка кода может выявить дефекты дизайна и способствовать обучению в команде разработки. Инструменты, такие как TFS и Collaborator от Smartbear, могут облегчить этот процесс.
В конечном счете, производительность должна быть приоритетом для большинства проектов. Следуя лучшим практикам и непрерывно улучшая SQL-код, разработчики могут обеспечить оптимальную производительность и поддерживаемые базы данных.
Спасибо за чтение! Следите за новыми советами и лучшими практиками по SQL Server в будущих блог-постах.