и правила, касающиеся данных, но из этого не следует необходимость полностью реа-лизовывать логическую модель данных в физической базе данных. Дело в том, что всегда остается возможность принять решение о том, например, чтобы ограничения, которым должны соответствовать данные, были реализованы исключительно в клиентской программе, но независимо от того, где будет реализовано требование, оно по-прежнему остается частью всесторонней логической модели данных. Из этого следует, что успешное решение всех проблем проектирования возможно лишь в результате создания качественной, глубоко продуманной логической модели данных, поскольку без использования логической хмодели данных невозможно подготовить физичес1сую модель данных и разработать проекты приложений. С другой стороны, только логическая модель позволяет достичь полкой уверенности в том, что все задачи проектирования действительно решены.

Обработка информации, представленной в виде файлов

Начнем описание темы этого раздела с определения преимуществ и недостатков типа данных BLOB. Сведения, приведенные ранее в настоящей книге, еще не позволяют читателю самостоятельно судить о том, следует ли применять данные типа BLOB в своих приложениях. Прежде всего следует отметить, что необходимость в использовании данных этого типа определяется тем, должна ли поддерживаться в приложении обратная совместимость.

В версии SQL Server 2005 появился целый ряд новых типов данных (varchar (max), nvarchar (max) и varbinary (max)), которые позволяют в весьма значительной степени упростить работу с данными типа BLOB. Если же данные типа BLOB используются в сочетании с совместимой моделью доступа к данным (с ADO.NET 2.0 или более высокой версией), то появляется возможность организовать доступ к этим данным BLOB по такому же принципу, как если бы это были данные, имеющие базовый тип данных с меньшим форматом представления (тип данных varchar, nvarchar или varbinary). Но, к сожалению, на практике по-прежнему очень часто возникает необходимость разрабатывать приложения, которые должны обеспечивать работу с СУБД SQL Server не только текущей версии, но и предыдущих версий, т.е. обеспечивать обратную совместимость, поэтому вместо типа данных varchar, nvarchar или varbinary приходится непосредственно использовать тип данных BLOB и осуществлять доступ к данным с помощью традиционного метода, предусматривающего последовательную обработку отдельных фрагментов данных (и характеризующегося чрезвычайно низким быстродействием). Но hpi один метод доступа к данным типа BLOB не позволяет компенсировать их принципиальный недостаток, связанный с тем, что большие объемы информации, представленные с помощью данных этого типа, обрабатываются очень медленно. Быстродействие любого приложения, в котором используются данные типа BLOB, становится очень низким.

Безусловно, данные типа BLOB могут оказаться буквальное незаменимыми, поскольку они позволяют выйти за рамки ограничения на размер строки, которое составляет 8 Кбайт (объем данных типа BLOB может достигать приблизительно 2 Гбайт). Наиболее существенный недостаток данных типа BLOB заключается в том, что средства обработки этих данных могут оказаться весьма неудобными в использовании (особенно если для обработки информации приходится применять устаревшие

Прежде чем воспользоваться этим способом, необходимо определить, обеспечивает ли файловая система более быстрый доступ к данным, чем база данных. По мнению автора, ответ на этот вопрос является положительным.

Ниже описаны два способа организации хранения значительных объемов данных в файловой системе. В первую очередь будет описан способ, который был реализован еще в предыдущих версиях SQL Server, а затем мы перейдем к описанию другого возможного способа, который получил распространение в связи с внедрением инфраструктуры .NET. Необходимо сразу же отметить, что успешно справиться с этой задачей можно только при том условии, что определенные работы будут проведены не только на серверном, но и на 1Слиентском компьютере, поскольку для обеспечения доступа к данным в файловой системе применяются не только сервер базы данных, но и средства поддержки файловой системы. Фактически при использовании первого способа доступа основная часть нагрузки снимается с сервера базы данных и передается на промежуточный уровень и в файловую систему.

На первых порах при освоении этого метода доступа можно попытаться организовать хранение данных в файловой системе не клиентского, а серверного компьютера. Для этого достаточно вьщелить один каталог, предназначенный для хранения в нем информации. В зависимости от характера конкретного прможения может также потребоваться предусмотреть в приложении промеж}точного уровня программные средства, позволяющие создавать по мере необходимости дополнительные каталоги.

Во всех операционных системах Windows применяются ограничения на количество файлов, которые могут храниться в одном каталоге. А с выходом 64-битовой операционной системы Windows максимально допустимое количество файлов в каталоге увеличилось до такой степени, что трудно представить себе приложение, в котором могло быть достигнуто это ограничение, и единственной реальной проблемой стало

типы данных и методы доступа). Но, по мнению автора, еще более важно то, что применение данных типа BLOB не позволяет достичь высокого быстродействия (я вынужден неоднократно подчеркивать эту мысль, чтобы читатель сумел окончательно сделать правильный вывод). Операции обработки данных типа BLOB выполняются намного медленнее по сравнению с операциями обработки данных любых других типов.

Причем этот недостаток данных указанного типа, по-видимому, является неустранимым. Безусловно, после появления каждой следующей версии СУБД SQL Server обнаруживается существенное повышение производительности операций обработки данных типа BLOB, но, несмотря на это, быстродействие приложений, в которых используются данные этого типа, оставляет желать лучшего.

Несмотря на отмеченные недостатки данных типа BLOB, они рассматриваются в первую очередь, когда возникает необходимость хранить крупные блоки текста или двоичных данных. Обычно для хранения больших объемов текстовых или двоичных данных, которые рассматриваются как единое целое, принято использовать данные типа BLOB, а если учесть новейшие достижения в области повышения производительности обработки данных типа BLOB, то, по-видимому, этот вариант является наиболее приемлемым, но в действительности имеется возможность подойти к решению этой задачи немного иначе. Проблему хранения крупных блоков данных можно решить, используя файлы вместо данных типа BLOB.

то, что по мере увеличения количества файлов в каталоге номинальная производительность системы снижается (операционные системы Windows по-прежнему отличаются тем, что операции доступа к файлам выполняются все более медленно по мере того, как увеличивается количество файлов в конкретном каталоге). В связи с этим необходимо заблаговременно выяснить, какое количество файлов потребуется для хранения информации, предназначенной для размещения в файловой системе. Если количество таких файлов достаточно велико (скажем, превышает 500), то в программном компоненте, обеспечивающем хранение данных типа BLOB в файловой системе, необходимо предусмотреть функции, позволяющие создавать новые каталоги после обнаружения того, что количество файлов в одном каталоге превышает допустимое, или по результатам проверки какого-то другого логического критерия.

При такой организации хранения данных типа BLOB ответственность за копирование информации BLOB в файл, предназначенный для ее хранения, возлагается на прикладное программное обеспечение. Если при этом копируемые данные уже имеют формат, соответствующий заранее заданному формату файла, то для копирования данных в файл достаточно выполнить команду на применяемом языке программирования, эквивалентную команде копирования (с учетом некоторых нюансов, которые будут вскоре описаны), а затем проверить, была ли эта команда выполнена успешно. Если же для вывода в файл предназначены потоковые данные, то данные, которые должны быть сохранены в файловой системе, необходимо подвергнуть определенной обработке и преобразовать в формат, позволяющий упростить их последующую выборку.

Рассматриваемый подход к организации хранения данных имеет весьма существенный недостаток, связанный с тем, что при его использовании могут возникать проблемы нарушения безопасности. Дело в том, что при этом информация хранится в файловой системе, которая находится вне области функционирования СУБД SQL Server, поэтому на хранимую информацию не распространяется также действие средств обеспечения безопасности данных SQL Server. Вместо этого остается возможность рассчитывать лишь на то, что системы защиты данных в сети и в файловой системе окажутся достаточно надежными.

На основании этого можно сделать вывод, что средства защиты данных СУБД SQL Server не позволяют предотвратить возможные нарушения конфиденциальности данных, последствия которых могут оказаться весьма опасными. Во-первых, для предотвращения несанкционированного доступа к данным, хранящимся в файлах, как правило, применяется такой подход, который предусматривает предоставление прав доступа на уровне каталогов, а это означает, что пользователь получает возможность просматривать не только файлы с требуемыми ему данными, но и все прочие файлы, находягциеся в каталоге. Этот недостаток можно было бы исправить, перейдя к использованию подхода, предусматривающего предоставление прав доступа на уровне отдельных файлов с использованием средств операционной системы Windows, но такой подход является очень трудоемким, а в случае Web-пppIлoжeния для его реализащш потребовалось бы даже применение на Web-сервере дополнительной библиотеки DLL. Во-вторых, предоставление доступа к файлам в каталоге влечет за собой то, что пользователи получают возможность вносить изменения в файлы непосредственно, без использования базы данньгх, а это может привести к нарушению синхронизации данных, хранящихся в базе данных и в файлах. Такая опасность вполне реальна.