В MS Access можно выделить три типа ключевых полей: простой ключ, составной ключ и счетчик. Обычно в

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

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

дополнительно

52 - 53. Структура бд в Access. Связь между таблицамиСредства Access для установления связей между таблицами.

52 База данных БД - это поименованная совокупность структурированных данных, описывающих состояние объектов одной предметной области и их отношения. Например, библиотечные и архивные системы, телефонные и адресные справочники, базы данных о наличии и движении товаров, о сотрудниках организации и др. Целью создания базы данных является упорядочение информации из одной предметной области, возможность поиска нужных данных и их обработки. Рассмотрим основные понятия БД:

Таблица - это основной объект базы данных, предназначенный для хранения элементарных данных, состоящих из записей строк и полей столбцов.

Элементарное данное - единица данных, описывающая один признак одного объекта предметной области. Например, фамилия конкретного читателя или название конкретной книги в библиотечной базе данных.

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

Запись - это совокупность логически связанных полей, данные из которых описывают все признаки одного объекта предметной области. Например, все данные об одном издании. В структуре двумерной таблицы ее аналог - строка. БД MS Access может содержать множество объектов:

Таблица является основным объектом базы данных. В MS Access вся информация хранятся в таблицах. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы поля, их типы и свойства.

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

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

Отчёт используется для отображения итоговых данных из таблиц и запросов в удобном для просмотра виде. В отчетах предусмотрены специальные средства

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

Страницы это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данных, но содержит компоненты, через которые осуществляется связь переданной Web-страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа.

Макросы и модули. Эти объекты предназначены как для автоматизации повторяющихся операций при работе с базой данных, так и для создания новых функций путем программирования. Макросы состоят из последовательности внутренних команд СУБД MS Access, а модули создаются средствами внешнего языка программирования. Это одно из средств, с помощью которых разработчик может заложить в базу нестандартные функциональные возможности, повысить быстродействие системы, а так же уровень ее защищенности.

52-53 Задание связей между таблицами происходит в окне схема данных,которое открывают кнопкой панели инструментов или командой Схема данных пункта меню Сервис. Открывается окно Добавление таблиц, на вкладке Таблицы которого нужно выбрать таблицы, между которыми устанавливаются связи, щелчком на кнопке Добавить. В окне Схема данных откроются списки полей этих таблиц. Одна из таблиц считается главной, а другая - связанной. Главная - это та таблица, которая участвует в связи своим ключевым полем. При нажатой кнопке на связываемом поле главной таблицы перевести курсор мыши на нужное поле связанной таблицы. При отпускании кнопки мыши автоматически открывается окно Изменение связей для настройки свойств связи. В этом окне можно изменить имена полей, участвующих в связи, и задать элементы управления для обеспечения условий целостности данных. Если установлен только флажок Обеспечение целостности данных, то удалять данные из ключевого поля главной таблицы нельзя. Если вместе с ним включены флажки Каскадное обновление связанных полей и Каскадное удаление связанных полей, то, соответственно, операции редактирования и удаление данных в ключевом поле главной таблицы разрешены, но сопровождаются автоматическими изменениями в связанной таблице. Образовавшееся межтабличная связь отображается в окне Схема данных в виде линии, соединяющей 2 поля разных таблиц. Т.о. , смысл создания реляционных связей между таблицами состоит, с одной стороны, в защите данных, а с другой стороны - в автоматизации внесения изменений сразу в несколько таблиц при изменениях в 1 таблице. При организации связи между таблицами следует иметь в виду, что связываемые

поля должны иметь один и тот же тип и одинаковые свойства или быть, по крайней мере, согласованными.

Расположение таблицы

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

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

Кроме того, в этом случае несколько увеличится размер файла базы данных (точнее файла DCT - мемо-файла), поскольку непосредственно в нем хранится относительный путь к включенным в него таблицам. Если таблицы расположены в той же директории, что и сам файл базы данных, то этого относительного пути просто нет. Справедливости ради, следует заметить, что относительный путь к базе данных хранится и в заголовках таблиц, которые в эту базу данных включены. Но на размер таблиц это не влияет, поскольку под этот относительный путь всегда выделяется фиксированное место вне зависимости от факта его наличия.

Собственно работа с таблицами

Как уже было замечено выше, таблицы всегда открываются в конкретной рабочей области и для перехода в нужную рабочую область есть 2 способа адресации: либо по номеру этой рабочей области, либо по имени алиаса (alias) таблицы открытой в этой рабочей области.

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

Рабочая область с номером 0

Отдельного упоминания заслуживает нулевая рабочая область. Ссылка на нулевую рабочую область означает ссылку на первую свободную рабочую область. Т.е. рабочую область, которая в настоящий момент не связана ни с какой таблицей

Такая адресация позволяет делать несколько вещей

Во-первых, это позволяет открывать новые таблицы не заботясь о том, не занята ли текущая рабочая область другой таблицей. Т.е. дается команда вида

Указание нулевой рабочей области необходимо потому, что в противном случае таблица будет открыта в текущей рабочей области одновременно закрыв таблицу, которая могла бы быть в ней открыта. А в таком синтаксисе открытие новой таблицы никак не повлияет на ранее открытые таблицы

Другое применение нулевой рабочей области - это настройки по умолчанию.

Например, Вы вероятно уже знаете, что любое View по-умолчанию открывается в режиме оптимистической буферизации строк (3) , но если Вам необходимо использовать его в режиме оптимистической буферизации таблиц (5) , то необходимо после его открытия сделать это переключение используя функцию CursorSetProp() примерно так

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

Замечу еще, что глобальная настрока нулевой рабочей области никак не затронет рабочие области, в которых уже есть открытые таблицы. Она влияет только на пока не используемые рабочие области.

Большая таблица

Очень часто в конференциях проскакивает словосочетание "большая таблица" .

Я бы сказал, что понятие "большая таблица" весьма субъективно. По моим наблюдениям, в большинстве случаев, под "большой" понимают такую таблицу, выполнение операций чтения/записи с которой занимает ощутимо заметное время. Заметное для пользователя.

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

Предельно допустимое количество записей, которое может содержаться в одной таблице - это 1 миллиард записей (1 billion) . Т.е. единица и девять нулей. Так вот, "большой" можно считать таблицу содержащую не менее нескольких миллионов записей .

Но опять-таки термин "большая" всплывает не тогда, когда оценивают просто количество записей, а когда оцениваю время выполнения некоторых операций с такими таблицами. Но ведь есть множество причин влияющих на время чтения/записи. Соответственно, та таблица, которая считается "большой" в одном случае в другом уже не такая "большая".

В очередной раз вспоминается лень американцев и их стремление все сокращать (впрочем русские здесь ушли еще дальше - могут сказать почти все используя только несколько специфических слов). Термин "курсор" употребляется сразу в нескольких смыслах в зависимости от контекста.

Курсор - это образ файла DBF открытого в одной из рабочих областей

Курсор - это временная таблица являющаяся результатом выполнения команды Select-SQL

Курсор - это указатель положения индикатора ввода текста с клавиатуры

Ну, последнее определение не очень-то интересно. В том смысле, что здесь все ясно, кроме того, почему этот термин был использован еще и для временных таблиц, ведь слово "cursor" собственно и переводится как "указатель" .

Курсор как образ файл DBF

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

Замечу еще, что курсор, как объект, используется не только как образ файлов DBF, но и как образ View . А View и таблица - это не одно и то же .

Курсор как временная таблица

Вот это наиболее употребительное использование данного термина. Собственно есть 2 способа создания таких курсоров

Первый способ - это использование команды CREATE CURSOR . Созданный таким способом курсор будет редактируемым. И это будет именно временная таблица, т.е. она будет автоматически уничтожена в момент закрытия. Ну про этот способ сказать особо нечего. Здесь нет каких-то проблем и особенностей

Второй способ - это использование опции CURSOR в команде SELECT-SQL . Примерно в следующем синтаксисе

Вот этот-то TmpTable и есть курсор

В зависимости от различных условий этот курсор может иметь разное физическое "воплощение" и разные свойства

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

Если будет возвращено имя файла с расширением DBF, то данный курсор является той же самой исходной таблицей с наложенным на нее фильтром.

Если Вы хотите при любых запросах быть уверенными, что курсор - это именно временная таблица, а не исходная таблица с наложенным фильтром, то Вам следует добавить опцию NOFILTER

Эта опция появилась только в 5 версии Visual FoxPro, хотя там она еще не была документирована. В более ранних версиях необходимо добавлять фиктивные условия или признаки группировки, чтобы исключить возможность оптимизации.

Однако если курсор - это временная таблица , то это еще не значит, что эта временная таблица будет непременно физически расположена на диске. Вполне возможно, что вся временная таблица целиком поместится в оперативную память. Т.е. функция DBF("TmpTable") будет исправно показывать некий временный файл, но попытка найти его физически на диске окончится неудачей и функция FILE(DBF("TmpTable")) вернет .F.

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

Еще один немаловажный вопрос связан с тем, что полученные таким образом курсоры нельзя редактировать. Они доступны только на чтение . Начиная с 7 версии Visual FoxPro для решения этой проблемы появилась специальная опция ReadWrite

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

Переоткрытый таким образом курсор TmpWriteTable уже можно будет редактировать

Курсоры можно индексировать также как и обычные таблицы. Правда если курсор открыт в режиме только для чтения, то Вы сможете создать для него только один индексный тэг.

Все созданные таким образом курсоры автоматически удаляются с диска (если временный файл физически был создан на диске) в момент их закрытия. Если Вы создали для такого курсора структурный индексный файл, то этот файл также будет автоматически удален в момент закрытия курсора.

Формирование имени курсора в команде Select-SQL

Это не такой простой вопрос, как может показаться. Проблема здесь в том, что имя курсора - это фактически алиас (alias) временной таблицы. Но в FoxPro в одном сеансе данных не может быть открыто 2 таблиц с одинаковыми алиасам.

Курсор всегда создается на машине клиента, поэтому конфликтов с другими пользователями можно не опасаться. Более того, даже если запущен дважды один и тот же проект на одной машине все-равно не будет конфликат связанного с одинаковыми именами курсоров, поскольку они открыты в разных сеансах данных. Конфликт возможен если Вы создаете несколько курсоров с одним и тем же именем в одном сеансе данных

Ну например, Вы открыли 2 формы использующих Default DataSession и в обоих создали курсор с одинаковым именем. В этом случае, курсор созданный позднее затрет курсор созданный ранее. При этом настройка SET SAFETY не играет никакой роли. Курсор будет пересоздан молча. Без каких-либо дополнительных запросов.

Избежать подобных конфликтов можно несколькими способами

Проблема в том, что функция SYS(2015) может содержать в возвращаемом значении как буквы, так и цифры. Это значит, что при использовании выделения строки по SubStr() Вы вполне можете получить первым символом цифру. А использование в качестве имени переменной цифры в синтаксисе FoxPro недопустимо и Вы неожиданно получите сообщение о синтаксической ошибке. Чтобы этого избежать следует либо принудительно подмешать букву

Соответсвенно выполнение запроса станет выглядеть так:

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

Поля таблицы

Поле таблицы - это столбец который Вы видите каждый раз открывая таблицу на просмотр.

Название полей таблицы

Поле таблицы, включенной в {базу данных} может содержать до 128 символов, содержать русские символы, цифры и некоторые спец.символы. Однако для упрощения работы в FoxPro я бы порекомендовал следующие ограничения в наименовании файла таблицы

Ну, например, если в таблице необходимо указать сумму платежа и сумму налога, то Вы конечно можете создать 2 поля Platezh1 и Platezh2 . Но в этом случае, вам каждый раз придется вспоминать, что собственно обозначает цифра 1, а что цифра 2. Если Вы работаете постоянно только с одним проектом, то это не страшно, как-нибудь да запомните. Но если Вы отложили этот проект и вернулсь к нему через несколько месяцев, то напряженные размышления на тему - а что это собственно такое? - Вам обеспечены. Гораздо разумнее дать значимые имена: Platezh и Nalog

Если воображение Вам напрочь отказывает и Вы не знаете как по другому назвать поле кроме как например "Order" или "Group" , то добавьте в качестве первого символа букву, обозначающую тип данных, используемых в данном поле. Например, "nOrder" или "cGroup"

Собственно работа с полями таблицы

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

Ключевое поле

Это одно из важнейших понятий, используемое при работе с таблицами и базами данных

Ключевое поле - это такое поле (или набор полей) по содержимому которого можно однозначно идентифицировать запись таблицы. Т.е. по значению ключевого поля всегда однозначно можно сказать о какой записи идет речь и не может существовать 2 записей с одинаковыми значениями ключевого поля.

Внешний ключ - это поле таблицы, содержащее в себе значение ключевого поля другой таблицы. Т.е. просто ссылка на запись другой таблицы.

Начну сразу с вывода:
Для большинства задач в FoxPro удобно использовать в качестве ключевого поля суррогатный ключ типа Integer. Ключевое поле желательно вводить для всех без исключения таблиц базы данных

Ну а теперь рассмотрим как же я дошел до выводов таких

Естесственные или Суррогатные ключи

До сих пор не утихают споры о том, что лучше использовать: суррогатные или естесственные ключи.

Естесственный ключ - это поле или набор полей, которые имеют некий физический смысл. Ну например, табельный номер, номер паспорта, и т.п.

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

Рассмотрим какие преимущества и недостатки имеют естесственные и суррогатные ключи

Фактически самый главный и определяющий критерий по которому можно судить о том, пригодно ли данное поле для использования его в качестве ключевого или нет - это однозначность идентификации записи. Здесь имеется в виду, действительно ли значение выбранного поля для каждой записи уникально?

Ну с суррогатным ключем все понятно - мы сами формируем его значение без участия со стороны пользователя, поэтому можем проследить за уникальностью, а вот как тут у естесственного ключа?

На первый взгляд кажется, что тоже все в порядке. Разве может номер паспорта быть не уникальным? Или табельный номер? Оказывается еще как может!

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

Например, если речь идет о некотором цифро-буквенном номере (номер паспорта) и пользователь ввел "123 АБВ", а надо было "423 АБВ", то синтаксически это правильно, но по содержанию - это ошибка. Если впоследствии окажется что теперь надо ввести новый номер паспорта, но уже "123 АБВ", то программа откажется это сделать, поскольку такой номер уже есть. А на что его исправить неизвестно, поскольку документов, с которых он был введен уже нет.

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

Опять же, не так давно в Российской Федерации были введены так называемые "Идентификационные Номера Налогоплательщика". Так называемые "ИНН". Ну казалось бы, ну вот он уникальный идентификатор контрагента. Но наша родная бюрократия и здесь сумела все испортить. Оказалось, что ИНН нарушает все критерии уникальности, в связи с некоторыми особенностями его формирования

В одной из конференций, один из посетителей выразился по этому поводу достаточно эмоционально

Я отдаю предпочтение СК просто потому, что СК предоставляет возможность пользователю решать, Иванов И.И. и Петров И.И. - один и тот же человек или разные. Может быть, он сменил фамилию, может быть даже пол, может быть он сменил и тип паспорта, и его номер. Может быть, он сменил гражданство, вернулся с войны без рук, ног и головы, наплодил детей, сделал пластическую операцию по изменению веса... Но от этого он не перестал быть самим собой.

Таким образом, в общем случае, естесственный ключ не обеспечивает главного - однозначности идентификации записи по значению ключевого поля. А если все-таки обеспечивает, то он перестает быть естесственным в первоначальном смысле этого слова, поскольку вынуждает пользователя приспосабливаться и изворачиваться.
Так почему же, несмотря на столь явные аргументы против, все равно есть достаточно большое количество приверженцев использования естесственного ключа?

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

Дело в том, что главным аргументом приверженцев естесственного ключа является его "понятность" пользователю. Т.е. предполагается, что пользователь что-то ищет опираясь на значение ключевого поля. Иными словами, пользователь сам вводит, исправляет и просматирвает значение ключевого поля.

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

Есть очень большое искушение не делать дополнительную таблицу с этими 3 записями, а просто использовать коды 1,2,3 Ну действительно, ну не может же пользователь изменить количество и название состояний. Вот тут приверженцы естесственного ключа и поднимают голос - дескать, что говорят программисту какие-то цифирки, пускай уж сразу слова пишет

В данном случае лично я рекомендовал бы не поддаваться искушению "упростить" базу данных и ввести-таки дополнительную служебную табличку с 3 записями состояния. Пусть даже пользователь и не имеет возможность ее редактировать. Вы сами убедитесь, насколько она окажется уместна, а в некоторых случаях просто незаменима при написании Вами программы.
Вывод однозначен - суррогатные ключи предпочтительнее по всем критериям перед естесственными ключами

Какой тип данных использовать: Character или Integer

Раньше, когда для хранения числовых данных в FoxPro существовали только поля типа Numeric перевес в аргументации склонялся в пользу использования полей типа Character , но с появлением полей типа Integer все стало не так однозначно

При сравнении способа хранения ключевого поля в символьном или числовом формате выдвигаются 3 аргумента

Числовые поля легче формировать

Тут числовые поля вне конкуренции, поскольку стандартным способом формирования числовых ключевых полей является "максимальное значение плюс один". В случае же символьных полей, как правило используется некий генератор псевдо-случайных чисел. Здесь не место, для обсуждения способа генерации символьных ключей, но используемые процедуры обычно достаточно сложны из-за сложности обеспечения действительно уникального значения.

Замечу еще, что не стоит для генерации нового значения ключа использовать именно определение максимального значения в текущей таблице. Это хорошо в однопользовательском режиме, но в многопользовательском Вы рискуете получить 2 одинаковых значения ключа при одновременном добавлении новой записи двумя пользователями одновременно. Обычно используют специальную служебную таблицу, хранящуюю значение последнего использованного (или первого не использованного) значения ключа. Примеры использования такой таблицы приведены в стандартных проектах примеров FoxPro: Solution.pjx (форма NewID.scx ) и TasTrade.pjx . А в 8 версии FoxPro появились автоинкрементные поля , которые совсем упростили данную задачу.

Символьные поля "экономичнее", т.е. можно уместить больше значений в том же размере

Начнем с вопроса, а сколько вообще необходимо значений для идентификации вообщех всех записей таблицы?

Из системных ограничений известно, что предельно допустимое количество записей в DBF-таблице - это 1 миллиард записей (1 billion) . Т.е. это единица и девять нулей

Поле типа Integer может принимать знаячение в диапазоне от -2,147,483,647 до 2,147,483,647. Ну, отрицательные значения как правило не используются, но и положительные значения в 2 раза больше, чем максимально возможное количество записей. С учетом возможного удаления записей - в самый раз.

Поскольку поле типа Integer физически занимает 4 байта (4 символа), то посмотрим, сколько же значений может быть присвоено при таком же размере для символьного поля

В одном байте может быть записано 256 значений, т.е. это составит 256**4=4,294,967,296. Но поскольку некоторые значения нельзя использовать по ряду соображений (например, символ перевода строки, Esc и т.п.), то получается, что в смысле количества значений поля типа Integer ничуть не уступает полю типа Caracter(4) , даже пожалуй несколько превосходит

Замечание

Следует заметить, что в FoxPro поля типа Numeric храняться как символьные поля, т.е. для хранения каждой цифры нужен один байт. Это значит, что если предполагаемое количество значений в данной таблице не превышает тысячи (меньше 4 символов), то возникает искушение "сэкономить" и вместо типа Integer ввести скажем поле типа N(2)

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

Символьные поля "универсальнее" при так назваемых задачах репликации

Репликация - это объединение информации из двух не связанных между собой баз данных, например, из двух филиалов одной организации территориально удаленных друг от друга

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

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

Надо ли использовать ключевое поле во всех без исключения таблицах

На первый взгляд, вопрос может показаться странным. Разве можно без ключевого поля? Оказывается, в некоторых случаях можно.

Например, для организации связи много-ко-многим стандартным способом является создание таблицы-посредника. Что имеется в виду?

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

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

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

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

Название ключевого поля

Поскольку ключевое поле - это обычное поле таблицы , то на него распространяются все рекомендации приведенные в разделе "Поля таблицы" . Однако поскольку это все-таки очень специфическое поле, то для него я бы добавил следующие рекомендации

Собственно работа с ключевыми полями таблицы

Такая стратегия сильно облегчает отлов ошибок пользователей, поскольку в большинстве случаев, если пользователь делает ошибку в документе, то он не исправляет ошибочный документ, а удаляет его и создает заново! Вот и докажи потом, что это не программа плохая!

Кроме того, такая стратегия позволяет с меньшими проблемами интегрировать несколько баз данных в один комплекс если в этом возникает необходимость.

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

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

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