(Возврат на основную страницу)
MySQL против «настоящих» СУБД
Одна из самых популярных СУБД — MySQL — анализируется с точки зрения надежности при хранении конфиденциальной информации. Это ответы эксперта Майкла Хотека (Michael Hotek) на вопросы, помещенные в интернет-форуме.
Вопрос: Я был бы признателен, если бы мне порекомендовали наиболее подходящую СУБД для хранения информации, доступной с Web-сайта. Сайт поддерживает электронную коммерцию, чат, доску объявлений (bulletin board), потоковое видео и приложение, используемое врачами для доступа к истории болезни своих пациентов. Я подумываю об использовании SQL Server, но мне также рекомендуют MySQL. Наш бюджет позволяет приобрести лицензии на SQL Server, но действительно ли он стоит своих денег? Существует ли лимит одновременно работающих пользователей для MySQL? Есть ли какие-то ограничения на число одновременных транзакций? Будет ли MySQL лучшим выбором, потому что она работает в среде Unix? Посоветуйте, пожалуйста.
Ответ: Вы храните в БД конфиденциальную информацию. Кроме того, вы стоите перед необходимостью защиты данных от несанкционированного доступа и разграничения прав на доступ к данным. Ни при каких (!) обстоятельствах я не доверил бы MySQL ничего конфиденциального. Уверен, что пациенты не обрадуются, если ваш сайт будет взломан и информация из их истории болезни будет украдена. Если кто-то рекомендует вам MySQL для хранения критически важной информации, я советую поискать другого консультанта.
Если говорить о возможных вариантах выбора СУБД для обслуживания Web-сайта, вам стоит рассмотреть SQL Server, Sybase, Oracle или DB2. Если мне когда-либо придется иметь дело с компанией, хранящей мои конфиденциальные данные в MySQL, я немедленно прерву с ней отношения и постараюсь организовать расследование, чтобы выяснить, как организовано хранение и защита тех данных, которые успели попасть в базу.
Вопрос: Тогда как вы можете объяснить, что БД под управлением SQL Server взламывают каждый месяц, если не каждую неделю? Я сам использую MySQL и стараюсь держаться от Microsoft подальше, поскольку один русский хакер недавно выложил в Интернет тысячи номеров кредитных карт и обосновал свои действия таким образом: «Я должен был это сделать, раз уж они настолько глупы, что доверили номера карточек Microsoft SQL Server».
Ответ: Неправильная практика обеспечения безопасности, неправильная практика развертывания приложений, неправильная практика разработки приложений и неправильная практика администрирования. Если сконфигурировать SQL Server, непосредственно выставленный в Интернет так, что он использует пустой пароль sa, ничего удивительного, что его взломают. Если сервер развернут с учетом правильного подхода по обеспечению безопасности, на него не попадут случайные люди. Этот хакер получил номера кредиток, потому что сервер не был надлежащим образом сконфигурирован.
Unix, mainframe, Windows… возьмите любую платформу или продукт — все они подвергаются атакам и иногда атака оказывается успешной. Успех хакеру обеспечивает неправильное конфигурирование и администрирование. Можно этого избежать? Естественно. Однако я должен сказать, что средства разграничения доступа, имеющиеся в SQL Server, на световые годы опережают то, что предлагает MySQL. как и Access, я рассматриваю MySQL как игрушку, вполне пригодную для хобби, но не для реальной работы.
Вот самый свежий пример: червь Slammer. Если взять моих клиентов, они в общей сложности используют более 50 000 экземпляров SQL Server. Все эти серверы хранят конфиденциальную и важную для ведения бизнеса информацию. Ни один из них не пострадал от червя. Ни один из них до сих пор не был взломан. Почему? Потому что они стоят за брандмауэрами. Административные бюджеты закрыты, и админи-страторы тщательно контролируют доступ к серверам. Все, что не нужно для работы, отключено. Системы профилируются на предмет выявления попыток проникновения, и когда такие попытки зафиксированы, в дело вступают специальные механизмы, которые блокируют хакера и отключают от системы.
Это очень упрощенный ответ на весьма сложный вопрос. Приведенный в вопросе пример — один состоявшийся случай успешного проникновения. В то же время есть миллионы примеров безуспешных попыток взлома.
MDX в Analysis Services
Вильям Пирсон (William Pearson)
Это первая статья из серии «MDX в Analysis Services», которая, я надеюсь, поможет новым пользователям быстро разобраться в языке запросов к многомерным источникам данных (multidimensional expressions, MDX).
Эта серия предназначена для того, чтобы показать практическое применение основ MDX, исходя из перспектив Microsoft SQL Server 2000 Analysis Services (далее — Analysis Services). В центре нашего внимания будет создание MDX-выражений, основанных на единичном и множественных значениях и направленных на создание запросов для использования в многомерных источниках данных. В каждой последующей статье будут рассматриваться новые возможности, позволяющие создавать и применять MDX-запросы в различных сценариях, разработанных для конкретных потребностей.
В серии «MDX в Analysis Services» мы сосредоточимся на построении практического фундамента, основанного на прагматическом подходе, который «испытывает» каждую вновь введенную концепцию, показывая, надеюсь, ее практическое значение. Мы пройдем через дискуссию о главных компонентах основных MDX-запросов и попробуем использовать MDX, чтобы лучше понять, какие возможности он предоставляет для извлечения информации из OLAP-кубов.
Серия «MDX в Analysis Services»:
В этой статье мы в общих чертах познакомимся с компонентами и возможностями MDX-выражений и будем:
Что необходимо для изучения данной серии
Серия «MDX в Analysis Services» предполагает, что на вашем компьютере установлены SQL Server 2000, Microsoft Excel 2000 и другие компоненты Microsoft Office 2000. Поскольку будут работать многие комбинации компьютеров, сетей и сетевых версий вышеупомянутых приложений, предположим, что эти приложения и основной описываемый компьютер соответствуют минимальным требованиям. Очевидно, что компьютер должен соответствовать системным требованиям для установки SQL Server 2000 (их легко найти на сайте Microsoft, как, впрочем, и огромное количество другой чрезвычайно полезной информации).
Для всех упражнений используются источники данных и примеры, устанавливаемые в ходе типовой (typical) установки Analysis Services.
Применение логических операторов для повышения производительности
Херве Роггеро (Herve Roggero)
Сначала управление логическими операторами может показаться достаточно сложной задачей. Однако при наличии опыта и терпения и при соответствующих условиях эти операторы могут обеспечивать заметное повышение производительности в производственной среде.
В этой статье сравниваются два метода достижения одного и того же результата: с использованием нормализованной модели или логических операторов. По существу, логические операторы дают возможность частично денормализовать вашу БД (денормализована она или нет).
Как правило, логические операторы могут обеспечить большие преимущества для БД оперативной обработки транзакций (On-Line Transaction Processing, OLTP), которые:
Неудобство логических операторов заключается в том, что они работают только с типом данных int (на самом деле они работают также и с типом данных bigint). Это ограничивает их использование для больших связанных таблиц (referenced table) — обычно логические операции применяются, если связанные таблицы имеют не больше 63 записей. Когда приходится иметь дело с большим числом записей, можно использовать другие средства, но это грозит возможным снижением производительности. Эти технические приемы включают в себя:
В этой статье мы будем использовать для хранения двоичных значений поле с целочисленным (integer) типом данных.
Давайте поиграем в блокирование администратора БД
Роберт Марда (Robert Marda)
Это невозможно, не так ли? Да, невозможно. Однако вы, несомненно, захотите ограничить действия неопытного администратора БД при помощи технических приемов, описываемых в этой статье. Подобные приемы будут ограждать вас и других пользователей от забывчивости в исполнении делового регламента, выполнения ненужных заданий или просто от случайного удаления таблиц.
Я уверен, что есть и другие пути реализации подобных задач, возможно, более продуманные. Но целью этой статьи является описание использования некоторых экстремальных методов, предусматривающих выполнение последовательности шагов по отмене действий пользователя, что, безусловно, требует некоторых знаний о системных таблицах.
Я планирую выполнить эту задачу путем изменения системных таблиц (также называемых системными каталогами), что вызовет осуждение многих администраторов БД. Microsoft не рекомендует этого делать. Возможно, на меня наложат клеймо безответственного разработчика. Но я делюсь этими приемами с единственной целью: показать, что вы можете сделать, если почувствуете необходимость использовать эти методы, скажем, в качестве шутки в своей среде разработки. Вы можете автоматически включить все технические приемы, описываемые мною в этой статье, в список наихудшей практики и не воспринимать их всерьез.
(Возврат на основную страницу)