Маскирование таблиц и полей.
Предположим, что злоумышленнику удалось обойти вашу защиту и добраться до таблиц. Как быть в этом случае? Здесь тоже можно подпортить «хакеру» немного крови. Как Вы называете таблицы? Русские версии Access понимает русские названия и поначалу таблицы имеют такие имена; Адрес организации, Поступление Товара, Транспортные накладные и т.п. Очень скоро разработчик приходит к пониманию, что пробелы в названиях сильно усложняют жизнь, и появляются названия АдресОрганизации, ПоступлениеТовара, ТоварноТранспортныеНакладные… Еще через некоторое время появляются таблицы с именами: Sotrudniki, Tovar, Otdel… И в конце концов появляются названия tblAdressOrg (или tbAdressOrg), tblOtdel, tblZarplata… То же самое происходит и с именами запросов, форм, макросов, отчетов, а так же с названиями полей в таблицах и контролов на форме. Для большей читабельности базы, заполняются параметры «Описание» таблиц, запросов, форм, отчетов, макросов, полей.
А теперь представьте себе такую картину. Вы открываете базу, а там Table01, Table02, Table03…. Form01, Form02…. Report01, Report02… Поля в таблице имеют наименование Field01, Field02… В общем Вы меня поняли. Но для этого у Вас на компе или на листочке всё должно быть расписано подробнейшим образом. Имя таблицы, её назначение, имя поля – характер информации. Это потребует дополнительных затрат рабочего времени и большей организованности в работе. Не все на это легко согласятся.
А как же связи между таблицами? Открыв схему данных можно легко отследить связи между таблицами и тогда… В книгах и на форумах высказывалось много соображений про полезность и необходимость установки связей между таблицами. И сохранение целостности данных, и каскадное удаление записей, и увеличение скорости выполнения запросов и т.д. и т.п. Я не буду возражать насчет полезности связей, но без них можно обойтись. Пусть меня ругают и тыка��т в меня пальцем, но я скажу, что создать довольно сложные приложения на Access можно и без создания схемы данных. Я это говорю из личного опыта. Но при этом все действия по сохранению целостности базы, удалению данных, разруливанию критических ситуаций Вы берете на себя. Это дополнительный код, это более тщательное программирование, дополнительный контроль при некоторых операциях (например – удалении). Более тщательный порядок при работе с таблицами. Всё это дополнительные затраты, но всё это не так сложно, как кажется на первый взгляд. А схему данных можно сделать и на бумаге. (Я так и делал).
А теперь, как всегда, критические замечания. Про неудобство составления запросов и работы с рекордсетами, я уже писал. И про дополнительные сложности в программировании при отсутствии схемы данных – тоже. А вот про то, что текст всех запросов можно спокойно просмотреть даже в MDE файле об этом не упоминал. Даже то, что формы нельзя править, не является препятствием, для определения запроса, на котором основана форма. Даже если вы вручную набрали текст в поле «Источник данных» не спасает его от просмотра через панель (форму) «Свойства». Терпеливый пользователь, посидев с бумагой и ручкой, может восстановить схему данных. Так что переходим к следующему уровню защиты – шифрованию данных. Но об этом в следующей статье.
|