Внешние источники данных: создание таблиц в MS SQL с помощью скриптов *.sql

Ужас, а не статья.... Для DBA слабо, для 1С программиста много. Для кого это написано?

Администратор базы данных (DataBase Administrator — DBA) — специалист, управляющий работой базы данных. Обычно обязан­ности DBA подразделяют на основные и дополнительные

Основные обязанности DBA :

Установка нового программного обеспечения. Установка новых версий Oracle, приложений и другого программного обеспечения, относящегося к администрированию СУБД. Предусматривает так­же обязательное тестирование устанавливаемых программ перед введением их в рабочую среду.

· Конфигурирование программного и аппаратного обеспечения. В большинстве случаев доступ к настройке программного и аппа­ратного обеспечения имеет только системный администратор, поэтому DBA должен производить установку программ, конфигу­рирование программного и аппаратного обеспечения только со­вместно с системным администратором.

· Обеспечение безопасности. Является одной из основных обя­занностей DBA. Управление безопасностью и администрирование включают в себя: добавление и удаление пользователей, управле­ние квотами, аудит и разрешение проблем безопасности.

· Настройка производительности. Даже хорошо настроенная си­стема нуждается в постоянной проверке производительности и периодической ее перенастройке. Иногда для этого достаточно изменить параметры системы или индексы, а может быть, пере­строить структуру таблиц.

· Резервное копирование и восстановление системы. Одна из глав­ных обязанностей DBA — постоянно сохранять данные в системе. Чтобы делать это эффективно, необходимо разработать процеду­ру резервного копирования и стратегию восстановления данных. Очень важно периодически тестировать отработанную схему ре­зервного копирования и восстановления данных.

· Процедура постоянного [планового) обслуживания. Обслужива­ние СУБД лучше всего производить рано утром либо по выход­ным дням, чтобы не нарушать работу пользователей. Обслужива­ние включает в себя: архивирование, тестирование и настройку системы. Администратор должен составить календарь планового обслуживания СУБД и довести его до сведения клиентов.

· Локализация неисправностей и восстановление системы после сбоя. Поскольку сбой системы приводит к возможности потери доступа пользователей к своим данным, DBA обязан как можно быстрее восстановить работу системы, т.е. он должен уметь пре­дусмотреть сбой и заранее иметь план восстановления системы после сбоя.

Дополнительные обязанности DBA :

Сводятся, как правило, к оказанию помощи отдельным клиентам и могут включать в себя следующие задачи администрирования :

· Анализ данных. Проводится для того, чтобы дать отдельным разработчикам или пользователям рекомендации по повышению производительности или эффективности хранения данных.

· Предварительная разработка БД. Поскольку DBA знает систе­му «изнутри», он может на предварительной стадии разработки структуры БД указать команде разработчиков на потенциальные проблемы и помочь в увеличении производительности программ.

· Оказание консультаций разработчикам по хранимым SQL-про­цедурам. DBA довольно часто привлекается к разрешению про­блем SQL-кода и разработке (написанию) хранимых процедур, т.е. он должен быть готов стать консультантом для разработчиков и пользователей.

· Разработка производственных стандартов и соглашений по име­нам. Это одна из основных организационных проблем управления. Поскольку в разработке и развертывании приложений могут при­нимать участие несколько различных групп, DBA должен прини­мать активное участие в решении проблемы их соответствия про­изводственным стандартам и соглашениям по именам.

· Документирование среды. DBA должен документировать каж­дый аспект среды СУБД, включая конфигурирование оборудова­ния, обновление и изменение программного обеспечения, воп­росы, связанные с изменением системы и ее параметров, и уметь полностью восстановить ее по документации в случае необходи­мости.

· Планирование нагрузки системы и необходимого объема памяти. Неотъемлемой частью работы DBA является определение необхо­димости приобретения дополнительных серверов, дополнитель­ной дисковой и оперативной памяти в целях удовлетворения воз­растающих потребностей пользователей. Прогнозируя ожидаемую потребность аппаратных средств, администратор обеспечивает надежность работы информационной системы предприятия.

Кто такой — DBA?

Существует большое количество различных режимов работы DBA и не существует хорошего описания содержания его работы. Из того, что я видел, есть несколько основных типов DBA:

Administrative DBA — Работа по поддержке сервера и обеспечение его работоспособности. Резервирование, защита, установка заплат и SP, настройка репликаций и т.д. А также всё, что касается фактического программного обеспечения сервера.

Development DBA — работы по формированию запросов, хранимых процедур и т.д., которые обеспечивают бизнес-задачи. Такой DBA — эквивалент программиста. Он, прежде всего, пишет T-SQL запросы.

Architect — Design schemas. Строит таблицы, FKs, PKs и т.д. Работа по построению структур, которые встречают бизнес-задачи общего характера. Разработанный таким DBA дизайн используется разработчиками и всеми DBA для поддержки пользовательских приложений.

Data Warehouse DBA. Это новая роль, отвечающая за объединённые данные из множественных источников, в хранилище данных. Вероятно, придется проектировать хранилище, оптимизировать данные хранилища, стандартизировать данные, обрабатывать данные перед загрузкой. В SQL Server, этот DBA использовал бы в основном DTS.

OLAP DBA. Строит многомерные кубы для поддержки задач принятия решений или OLAP систем. Основной язык в SQL Server — это MDX, а не SQL.

Быть DBA (вообще) утомительное занятие. Вы должны планировать развитие базы на будущее, резервировать место, где ваша схема будет размещаться или расширяться. План роста чреват множеством ошибок и просчётов. Эта работа не похожа на программирование с помощью «C» или Visual Basic, когда ответственность ограничивается уровнем пользовательского приложения. Ваши решения затрагивают все данные и имеют далеко идущие последствия. Так как Вы работаете в ориентируемой на массивы данных среде (set-oriented), Вы можете легко допустить ошибку, которая затронет большое количество элементов этих данных. В отличие от класса или структуры, где Вы имеете дело с не большими порциями данных (то есть, один пользователь), единственный SQL запрос может затронуть всех пользователей структуры. Скольких из Вас мучили сомнения при написании delete <имя_таблицы> с предложением where?